Null Pointer

-------------------------------------------------------------------------------------------------------------

 

                                               5. Null Pointers

 ----------------------------------------------------------------------------------

 Question 5.1

Q: What is this infamous null pointer, anyway?
A: The language definition states that for each pointer type, there is a special value--the ``null pointer''--which is distinguishable from all other pointer values and which is ``guaranteed to compare unequal to a pointer to any object or function.'' That is, a null pointer points definitively nowhere; it is not the address of any object or function. The address-of operator & will never yield a null pointer, nor will a successful call to malloc.[(malloc does return a null pointer when it fails, and this is a typical use of null pointers: as a ``special'' pointer value with some other meaning, usually ``not allocated'' or ``not pointing anywhere yet.'')
A null pointer is conceptually different from an uninitialized pointer. A null pointer is known not to point to any object or function; an uninitialized pointer might point anywhere. See also questions 1.30, 7.1, and 7.31.
As mentioned above, there is a null pointer for each pointer type, and the internal values of null pointers for different types may be different. Although programmers need not know the internal values, the compiler must always be informed which type of null pointer is required, so that it can make the distinction if necessary (see questions 5.2, 5.5, and 5.6).

----------------------------------------------------------------------------------

Question 5.2

Q: How do I get a null pointer in my programs?
A: With a null pointer constant.
According to the language definition, an ``integral constant expression with the value 0'' in a pointer context is converted into a null pointer at compile time. That is, in an initialization, assignment, or comparison when one side is a variable or expression of pointer type, the compiler can tell that a constant 0 on the other side requests a null pointer, and generate the correctly-typed null pointer value. Therefore, the following fragments are perfectly legal:
    char *p = 0;
    if(p != 0)
(See also question 5.3.)
However, an argument being passed to a function is not necessarily recognizable as a pointer context, and the compiler may not be able to tell that an unadorned 0 ``means'' a null pointer. To generate a null pointer in a function call context, an explicit cast may be required, to force the 0 to be recognized as a pointer. For example, the Unix system call execl takes a variable-length, null-pointer-terminated list of character pointer arguments, and is correctly called like this:
    execl("/bin/sh", "sh", "-c", "date", (char *)0);
If the (char *) cast on the last argument were omitted, the compiler would not know to pass a null pointer, and would pass an integer 0 instead. (Note that many Unix manuals get this example wrong; see also question 5.11.)
When function prototypes are in scope, argument passing becomes an ``assignment context,'' and most casts may safely be omitted, since the prototype tells the compiler that a pointer is required, and of which type, enabling it to correctly convert an unadorned 0. Function prototypes cannot provide the types for variable arguments in variable-length argument lists however, so explicit casts are still required for those arguments. (See also question 15.3.) It is probably safest to properly cast all null pointer constants in function calls, to guard against varargs functions or those without prototypes.
Here is a summary of the rules for when null pointer constants may be used by themselves, and when they require explicit casts:

----------------------------------------------------------------------------------

  Question 5.3

Q: Is the abbreviated pointer comparison ``if(p)'' to test for non-null pointers valid? What if the internal representation for null pointers is nonzero?
A: It is always valid.
When C requires the Boolean value of an expression, a false value is inferred when the expression compares equal to zero, and a true value otherwise. That is, whenever one writes
    if(expr)
where ``expr'' is any expression at all, the compiler essentially acts as if it had been written as
    if((expr) != 0)
Substituting the trivial pointer expression ``p'' for ``expr'', we have
    if(p)    is equivalent to    if(p != 0)
and this is a comparison context, so the compiler can tell that the (implicit) 0 is actually a null pointer constant, and use the correct null pointer value. There is no trickery involved here; compilers do work this way, and generate identical code for both constructs. The internal representation of a null pointer does not matter.
The boolean negation operator, !, can be described as follows:
    !expr    is essentially equivalent to    (expr)?0:1
        or to    ((expr) == 0)
which leads to the conclusion that
    if(!p)    is equivalent to    if(p == 0)
``Abbreviations'' such as if(p), though perfectly legal[, are considered by some to be bad style (and by others to be good style; see question 17.10).
See also question 9.2.
References: K&R2 Sec. A7.4.7 p. 204
ISO Sec. 6.3.3.3, Sec. 6.3.9, Sec. 6.3.13, Sec. 6.3.14, Sec. 6.3.15, Sec. 6.6.4.1, Sec. 6.6.5
H&S Sec. 5.3.2 p. 122

----------------------------------------------------------------------------------

  Question 5.4

Q: What is NULL and how is it defined?
A: As a matter of style, many programmers prefer not to have unadorned 0's scattered through their programs, some representing numbers and some representing pointers. Therefore, the preprocessor macro NULL is defined (by several headers, including <stdio.h> and <stddef.h>) as a null pointer constant, typically 0 or ((void *)0) (see also question 5.6). A programmer who wishes to make explicit the distinction between 0 the integer and 0 the null pointer constant can then use NULL whenever a null pointer is required.
Using NULL is a stylistic convention only; the preprocessor turns NULL back into 0 which is then recognized by the compiler, in pointer contexts, as before. In particular, a cast may still be necessary before NULL (as before 0) in a function call argument. The table under question 5.2 above applies for NULL as well as 0 (an unadorned NULL is equivalent to an unadorned 0).
NULL should be used only as a pointer constant; see question 5.9.

----------------------------------------------------------------------------------

Question 5.5

Q: How should NULL be defined on a machine which uses a nonzero bit pattern as the internal representation of a null pointer?
A: The same as on any other machine: as 0 (or some version of 0; see question 5.4).
Whenever a programmer requests a null pointer, either by writing ``0'' or ``NULL'', it is the compiler's responsibility to generate whatever bit pattern the machine uses for that null pointer. (Again, the compiler can tell that an unadorned 0 requests a null pointer when the 0 is in a pointer context; see question 5.2.) Therefore, #defining NULL as 0 on a machine for which internal null pointers are nonzero is as valid as on any other: the compiler must always be able to generate the machine's correct null pointers in response to unadorned 0's seen in pointer contexts. A constant 0 is a null pointer constant; NULL is just a convenient name for it (see also question 5.13).
(Section 4.1.5 of the C Standard states that NULL ``expands to an implementation-defined null pointer constant,'' which means that the implementation gets to choose which form of 0 to use and whether to use a void * cast; see questions 5.6 and 5.7. ``Implementation-defined'' here does not mean that NULL might be #defined to match some implementation-specific nonzero internal null pointer value.)

----------------------------------------------------------------------------------

Question 5.6

Q: If NULL were defined as follows:
    #define NULL ((char *)0)
wouldn't that make function calls which pass an uncast NULL work?
A: Not in the most general case. The complication is that there are machines which use different internal representations for pointers to different types of data. The suggested definition would make uncast NULL arguments to functions expecting pointers to characters work correctly, but pointer arguments of other types could still (in the absence of prototypes) require explicit casts. Furthermore, legal constructions such as
    FILE *fp = NULL;
could fail.
Nevertheless, ANSI C allows the alternate definition
    #define NULL ((void *)0)
for NULL. [Besides potentially helping incorrect programs to work (but only on machines with homogeneous pointers, thus questionably valid assistance), this definition may catch programs which use NULL incorrectly (e.g. when the ASCII NUL character was really intended; see question 5.9). See also question 5.7.
At any rate, ANSI function prototypes ensure that most (though not quite all; see question 5.2) pointer arguments are converted correctly when passed as function arguments, so the question is largely moot.
Programmers who are accustomed to modern, ``flat'' memory architectures may find the idea of ``different kinds of pointers'' very difficult to accept. See question 5.17 for some examples.
References: Rationale Sec. 4.1.5

----------------------------------------------------------------------------------

  Question 5.7

Q: My vendor provides header files that #define NULL as 0L. Why?

A: Some programs carelessly attempt to generate null pointers by using the NULL macro, without casts, in non-pointer contexts. (Doing so is not guaranteed to work; see questions 5.2 and 5.11.) On machines which have pointers larger than integers (such as PC compatibles in ``large'' model; see also question 5.17), a particular definition of NULL such as 0L can help these incorrect programs to work. (0L is a perfectly valid definition of NULL; it is an ``integral constant expression with value 0.'') Whether it is wise to coddle incorrect programs is debatable; see also question 5.6 and section 17.
References: Rationale Sec. 4.1.5
H&S Sec. 5.3.2 pp. 121-2

----------------------------------------------------------------------------------

Question 5.8

Q: Is NULL valid for pointers to functions?
A: Yes (but see question 4.13).

----------------------------------------------------------------------------------

Question 5.9

Q: If NULL and 0 are equivalent as null pointer constants, which should I use?
A: Many programmers believe that NULL should be used in all pointer contexts, as a reminder that the value is to be thought of as a pointer. Others feel that the confusion surrounding NULL and 0 is only compounded by hiding 0 behind a macro, and prefer to use unadorned 0 instead. There is no one right answer. (See also questions 9.4 and 17.10.) C programmers must understand that NULL and 0 are interchangeable in pointer contexts, and that an uncast 0 is perfectly acceptable. Any usage of NULL (as opposed to 0) should be considered a gentle reminder that a pointer is involved; programmers should not depend on it (either for their own understanding or the compiler's) for distinguishing pointer 0's from integer 0's.
It is only in pointer contexts that NULL and 0 are equivalent. NULL should not be used when another kind of 0 is required, even though it might work, because doing so sends the wrong stylistic message. (Furthermore, ANSI allows the definition of NULL to be ((void *)0), which will not work at all in non-pointer contexts.) In particular, do not use NULL when the ASCII null character (NUL) is desired. Provide your own definition
    #define NUL '\0'
if you must.

----------------------------------------------------------------------------------

 Question 5.10

Q: But wouldn't it be better to use NULL (rather than 0), in case the value of NULL changes, perhaps on a machine with nonzero internal null pointers?
A: No. (Using NULL may be preferable, but not for this reason.) Although symbolic constants are often used in place of numbers because the numbers might change, this is not the reason that NULL is used in place of 0. Once again, the language guarantees that source-code 0's (in pointer contexts) generate null pointers. NULL is used only as a stylistic convention. See questions 5.5 and 9.4.

----------------------------------------------------------------------------------

  Question 5.11

Q: I once used a compiler that wouldn't work unless NULL was used.
A: Unless the code being compiled was nonportable, that compiler was probably broken.
Perhaps the code used something like this nonportable version of an example from question 5.2:
    execl("/bin/sh", "sh", "-c", "date", NULL);    /* WRONG */
Under a compiler which defines NULL to ((void *)0) (see question 5.6), this code will happen to work. [However, if pointers and integers have different sizes or representations, the (equally incorrect) code
    execl("/bin/sh", "sh", "-c", "date", 0);    /* WRONG */
may not work.
Correct, portable code uses an explicit cast:
    execl("/bin/sh", "sh", "-c", "date", (char *)NULL);
With the cast, the code works correctly no matter what the machine's integer and pointer representations are, and no matter which form of null pointer constant the compiler has chosen as the definition of NULL. (The code fragment in question 5.2, which used 0 instead of NULL, is equally correct; see also question 5.9.) (In general, making decisions about a language based on the behavior of one particular compiler is likely to be counterproductive.)

----------------------------------------------------------------------------------

  Question 5.12

Q: I use the preprocessor macro
#define Nullptr(type) (type *)0
to help me build null pointers of the correct type.
A: This trick, though popular and superficially attractive, does not buy much. It is not needed in assignments or comparisons; see question 5.2. (It does not even save keystrokes.) See also questions 9.1 and 10.2.

----------------------------------------------------------------------------------

  Question 5.13

Q: This is strange. NULL is guaranteed to be 0, but the null pointer is not?
A: When the term ``null'' or ``NULL'' is casually used, one of several things may be meant:
The conceptual null pointer, the abstract language concept defined in question 5.1. It is implemented with...
The internal (or run-time) representation of a null pointer, which may or may not be all-bits-0 and which may be different for different pointer types. The actual values should be of concern only to compiler writers. Authors of C programs never see them, since they use...
The null pointer constant, which is a constant integer 0 [(see question 5.2). It is often hidden behind...
The NULL macro, which is #defined to be 0 (see question 5.4). Finally, as red herrings, we have...
The ASCII null character (NUL), which does have all bits zero, but has no necessary relation to the null pointer except in name; and...
The ``null string,'' which is another name for the empty string (""). Using the term ``null string'' can be confusing in C, because an empty string involves a null ('\0') character, but not a null pointer, which brings us full circle...
In other words, to paraphrase the White Knight's description of his song in Through the Looking-Glass, the name of the null pointer is ``0'', but the name of the null pointer is called ``NULL'' (and we're not sure what the null pointer is).
This document uses the phrase ``null pointer'' (in lower case) for sense 1, the token ``0'' or the phrase ``null pointer constant'' for sense 3, and the capitalized word ``NULL'' for sense 4.[

----------------------------------------------------------------------------------

Question 5.14

Q: Why is there so much confusion surrounding null pointers? Why do these questions come up so often?

A: C programmers traditionally like to know a lot (perhaps more than they need to) about the underlying machine implementation. The fact that null pointers are represented both in source code, and internally to most machines, as zero invites unwarranted assumptions. The use of a preprocessor macro (NULL) may seem to suggest that the value could change some day, or on some weird machine. The construct ``if(p == 0)'' is easily misread as calling for conversion of p to an integral type, rather than 0 to a pointer type, before the comparison. Finally, the distinction between the several uses of the term ``null'' (listed in question 5.13) is often overlooked.
One good way to wade out of the confusion is to imagine that C used a keyword (perhaps nil, like Pascal) as a null pointer constant. The compiler could either turn nil into the appropriate type of null pointer when it could unambiguously determine that type from the source code, or complain when it could not. Now in fact, in C the keyword for a null pointer constant is not nil but 0, which works almost as well, except that an uncast 0 in a non-pointer context generates an integer zero instead of an error message, and if that uncast 0 was supposed to be a null pointer constant, the resulting program may not work.
Additional links: an article by Richard Stamp with another angle on the NULL/0 distinction

----------------------------------------------------------------------------------

Question 5.15

Q: I'm confused. I just can't understand all this null pointer stuff.
A: Here are two simple rules you can follow:
When you want a null pointer constant in source code, use ``0'' or ``NULL''.
If the usage of ``0'' or ``NULL'' is an argument in a function call, cast it to the pointer type expected by the function being called.
The rest of the discussion has to do with other people's misunderstandings, with the internal representation of null pointers (which you shouldn't need to know), and with the complexities of function prototypes. (Taking those complexities into account, we find that rule 2 is conservative[, of course; but it doesn't hurt.) Understand questions 5.1, 5.2, and 5.4, and consider 5.3, 5.9, 5.13, and 5.14, and you'll do fine.

----------------------------------------------------------------------------------

Question 5.16

Q: Given all the confusion surrounding null pointers, wouldn't it be easier simply to require them to be represented internally by zeroes?
A: Some implementations naturally represent null pointers by special, nonzero bit patterns, particularly when it can be arranged that inadvertently using those values triggers automatic hardware traps. Requiring null pointers to be represented internally as 0, and therefore disallowing use of the special, nonzero values, would be an unfortunate step backwards, because catching errors which result in invalid accesses is a Good Thing.
Besides, what would such a requirement really accomplish? Proper understanding of null pointers does not require knowledge of the internal representation, whether zero or nonzero. Assuming that null pointers are internally zero does not make any code easier to write (except for a certain ill-advised usage of calloc; see question 7.31). Known-zero internal pointers would not reduce the need for casts in function calls, because the size of the pointer might still be different from that of an int. (If ``nil'' were used to request null pointers, as mentioned in question 5.14, the urge to assume an internal zero representation would not even arise.)

----------------------------------------------------------------------------------

pointers

----------------------------------------------------------------------------------

Pointers

----------------------------------------------------------------------------------

Question 4.1

Q: What are pointers really good for, anyway?
A: They're good for lots of things, such as:
dynamically-allocated arrays (see questions 6.14 and 6.16)
generic access to several similar variables
(simulated) by-reference function parameters (see question 4.8 and 20.1)
malloc'ed data structures of all kinds, especially trees and linked lists
walking over arrays (for example, while parsing strings)
efficient, by-reference ``copies'' of arrays and structures, especially as function parameters
(Note that this is hardly a comprehensive list!)
See also question 6.8.

----------------------------------------------------------------------------------

  Question 4.2

Q: I'm trying to declare a pointer and allocate some space for it, but it's not working. What's wrong with this code?
char *p;
*p = malloc(10);
A: The pointer you declared is p, not *p. When you're manipulating the pointer itself (for example when you're setting it to make it point somewhere), you just use the name of the pointer:
    p = malloc(10);
It's when you're manipulating the pointed-to memory that you use * as an indirection operator:
    *p = 'H';
(It's easy to make the mistake shown in the question, though, because if you had used the malloc call as an initializer in the declaration of a local variable, it would have looked like this:
    char *p = malloc(10);
When you break an initialized pointer declaration up into a declaration and a later assignment, you have to remember to remove the *.)
In summary, in an expression, p is the pointer and *p is what it points to (a char, in this example).
See also questions 1.21, 7.1, 7.3c, and 8.3.

----------------------------------------------------------------------------------

  Question 4.3

Q: Does *p++ increment p, or what it points to?
A: The postfix ++ and -- operators essentially have higher precedence than the prefix unary operators. Therefore, *p++ is equivalent to *(p++); it increments p, and returns the value which p pointed to before p was incremented. To increment the value pointed to by p, use (*p)++ (or perhaps ++*p, if the evaluation order of the side effect doesn't matter).

----------------------------------------------------------------------------------

Question 4.4

Q: I'm trying to use pointers to manipulate an array of ints. What's wrong with this code?
    int array[5], i, *ip;
    for(i = 0; i < 5; i++) array[i] = i;
    ip = array;
    printf("%d\n", *(ip + 3 * sizeof(int)));
I expected the last line to print 3, but it printed garbage.
A: You're doing a bit more work than you have to, or should. Pointer arithmetic in C is always automatically scaled by the size of the objects pointed to. What you want to say is simply
    printf("%d\n", *(ip + 3));    /* or ip[3] -- see Q 6.3 */
which will print the third element of the array. In code like this, you don't need to worry about scaling by the size of the pointed-to elements--by attempting to do so explicitly, you inadvertently tried to access a nonexistent element past the end of the array (probably array[6] or array[12], depending on sizeof(int) on your machine).

----------------------------------------------------------------------------------

  Question 4.5

Q: I have a char * pointer that happens to point to some ints, and I want to step it over them. Why doesn't
((int *)p)++;
work?
A: In C, a cast operator does not mean ``pretend these bits have a different type, and treat them accordingly''; it is a conversion operator, and by definition it yields an rvalue, which cannot be assigned to, or incremented with ++. (It is either an accident or a deliberate but nonstandard extension if a particular compiler accepts expressions such as the above.) Say what you mean: use
    p = (char *)((int *)p + 1);
or (since p is a char *) simply
    p += sizeof(int);
or (to be really explicit)
    int *ip = (int *)p;
    p = (char *)(ip + 1);
When possible, however, you should choose appropriate pointer types in the first place, rather than trying to treat one type as another.
See also question 16.7.

----------------------------------------------------------------------------------

  Question 4.6

Q: Why can't I perform arithmetic on a void * pointer?

A: See question 11.24.

----------------------------------------------------------------------------------

Question 4.7

Q: I've got some code that's trying to unpack external structures, but it's crashing with a message about an ``unaligned access.'' What does this mean?
A: See question 16.7.

----------------------------------------------------------------------------------

  Question 4.8

Q: I have a function which accepts, and is supposed to initialize, a pointer:
    void f(int *ip)
    {
        static int dummy = 5;
        ip = &dummy;
    }
But when I call it like this:
    int *ip;
    f(ip);
the pointer in the caller remains unchanged.
A: Are you sure the function initialized what you thought it did? Remember that arguments in C are passed by value. In the code above, the called function alters only the passed copy of the pointer. To make it work as you expect, one fix is to pass the address of the pointer (the function ends up accepting a pointer-to-a-pointer; in this case, we're essentially simulating pass by reference):
    void f(ipp)
    int **ipp;
    {
        static int dummy = 5;
        *ipp = &dummy;
    }

    ...

    int *ip;
    f(&ip);
Another solution is to have the function return the pointer:
    int *f()
    {
        static int dummy = 5;
        return &dummy;
    }

    ...

    int *ip = f();

----------------------------------------------------------------------------------

  Question 4.9

Q: Suppose I want to write a function that takes a generic pointer as an argument and I want to simulate passing it by reference. Can I give the formal parameter type void **, and do something like this?
    void f(void **);
    double *dp;
    f((void **)&dp);

A: Not portably. Code like this may work and is sometimes recommended, but it relies on all pointer types having the same internal representation (which is common, but not universal; see question 5.17).
There is no generic pointer-to-pointer type in C. void * acts as a generic pointer only because conversions (if necessary) are applied automatically when other pointer types are assigned to and from void *'s; these conversions cannot be performed if an attempt is made to indirect upon a void ** value which points at a pointer type other than void *. When you make use of a void ** pointer value (for instance, when you use the * operator to access the void * value to which the void ** points), the compiler has no way of knowing whether that void * value was once converted from some other pointer type. It must assume that it is nothing more than a void *; it cannot perform any implicit conversions.
In other words, any void ** value you play with must be the address of an actual void * value somewhere; casts like (void **)&dp, though they may shut the compiler up, are nonportable (and may not even do what you want; see also question 13.9). If the pointer that the void ** points to is not a void *, and if it has a different size or representation than a void *, then the compiler isn't going to be able to access it correctly.
To make the code fragment above work, you'd have to use an intermediate void * variable:
    double *dp;
    void *vp = dp;
    f(&vp);
    dp = vp;
The assignments to and from vp give the compiler the opportunity to perform any conversions, if necessary.
Again, the discussion so far assumes that different pointer types might have different sizes or representations, which is rare today, but not unheard of. To appreciate the problem with void ** more clearly, compare the situation to an analogous one involving, say, types int and double, which probably have different sizes and certainly have different representations. If we have a function
    void incme(double *p)
    {
        *p += 1;
    }
then we can do something like
    int i = 1;
    double d = i;
    incme(&d);
    i = d;
and i will be incremented by 1. (This is analogous to the correct void ** code involving the auxiliary vp.) If, on the other hand, we were to attempt something like
    int i = 1;
    incme((double *)&i);    /* WRONG */
(this code is analogous to the fragment in the question), it would be highly unlikely to work.

----------------------------------------------------------------------------------

Question 4.10

Q: I have a function
    extern int f(int *);
which accepts a pointer to an int. How can I pass a constant by reference? A call like
    f(&5);
doesn't seem to work.

A: In C99, you can use a ``compound literal'':
    f((int[]){5});
Prior to C99, you couldn't do this directly; you had to declare a temporary variable, and then pass its address to the function:
    int five = 5;
    f(&five);
In C, a function that accepts a pointer to a value (rather than simply accepting the value itself) probably intends to modify the pointed-to value, so it may be a bad idea to pass pointers to constants. [footnote] Indeed, if f is in fact declared as accepting an int *, a diagnostic is required if you attempt to pass it a pointer to a const int. (f could be declared as accepting a const int * if it promises not to modify the pointed-to value.)

----------------------------------------------------------------------------------

Question 4.11

Q: Does C even have ``pass by reference''?

A: Not really.
Strictly speaking, C always uses pass by value. You can simulate pass by reference yourself, by defining functions which accept pointers and then using the & operator when calling, and the compiler will essentially simulate it for you when you pass an array to a function (by passing a pointer instead, see question 6.4 et al.).
Another way of looking at it is that if an parameter has type, say, int * then an integer is being passed by reference and a pointer to an integer is being passed by value.
Fundamentally, C has nothing truly equivalent to formal pass by reference or C++ reference parameters. (On the other hand, function-like preprocessor macros can provide a form of ``pass by name''.)
See also questions 4.8, 7.9, 12.27, and 20.1.
Additional links: A message of mine further explaining how a function can modify a caller's passed array.

----------------------------------------------------------------------------------

Question 4.12

Q: I've seen different syntax used for calling functions via pointers. What's the story?

A: Originally, a pointer to a function had to be ``turned into'' a ``real'' function, with the * operator, before calling:
    int r, (*fp)(), func();
    fp = func;
    r = (*fp)();
The interpretation of the last line is clear: fp is a pointer to function, so *fp is the function; append an argument list in parentheses (and extra parentheses around *fp to get the precedence right), and you've got a function call.
It can also be argued that functions are always called via pointers, and that ``real'' function names always decay implicitly into pointers (in expressions, as they do in initializations; see question 1.34). This reasoning means that
    r = fp();
is legal and works correctly, whether fp is the name of a function or a pointer to one. (The usage has always been unambiguous; there is nothing you ever could have done with a function pointer followed by an argument list except call the function pointed to.)
The ANSI C Standard essentially adopts the latter interpretation, meaning that the explicit * is not required, though it is still allowed.
See also question 1.34.

----------------------------------------------------------------------------------

Question 4.13

Q: What's the total generic pointer type? My compiler complained when I tried to stuff function pointers into a void *.

A: There is no ``total generic pointer type.''
void *'s are only guaranteed to hold object (i.e. data) pointers; it is not portable to convert a function pointer to type void *. (On some machines, function addresses can be very large, bigger than any data pointers.)
It is guaranteed, however, that all function pointers can be interconverted, as long as they are converted back to an appropriate type before calling. Therefore, you can pick any function type (usually int (*)() or void (*)(), that is, pointer to function of unspecified arguments returning int or void) as a generic function pointer. When you need a place to hold object and function pointers interchangeably, the portable solution is to use a union of a void * and a generic function pointer (of whichever type you choose).
See also questions 1.22 and 5.8.

----------------------------------------------------------------------------------

Question 4.14

Q: How are integers converted to and from pointers? Can I temporarily stuff an integer into a pointer, or vice versa?
A: Once upon a time, it was guaranteed that a pointer could be converted to an integer (though one never knew whether an int or a long might be required), and that an integer could be converted to a pointer, and that a pointer remained unchanged when converted to a (large enough) integer and back again, and that the conversions (and any mapping) were intended to be ``unsurprising to those who know the addressing structure of the machine.'' In other words, there is some precedent and support for integer/pointer conversions, but they have always been machine dependent, and hence nonportable. Explicit casts have always been required (though early compilers rarely complained if you left them out).
The ANSI/ISO C Standard, in order to ensure that C is widely implementable, has weakened those earlier guarantees. Pointer-to-integer and integer-to-pointer conversions are implementation-defined (see question 11.33), and there is no longer any guarantee that pointers can be converted to integers and back, without change.
Forcing pointers into integers, or integers into pointers, has never been good practice. When you need a generic slot that can hold either kind of data, a union is a much better idea.
See also questions 4.15, 5.18, and 19.25.

----------------------------------------------------------------------------------

  Question 4.15

Q: How do I convert an int to a char *? I tried a cast, but it's not working.
A: It depends on what you're trying to do. If you tried a cast but it's not working, you're probably trying to convert an integer to a string, in which case see question 13.1. If you're trying to convert an integer to a character, see question 8.6. If you're trying to set a pointer to point to a particular memory address, see question 19.25.

----------------------------------------------------------------------------------

  Question 4.16

Q: What's wrong with this declaration?
char* p1, p2;
I get errors when I try to use p2.
A: See question 1.5.

----------------------------------------------------------------------------------

  Question 4.17

Q: What are ``near'' and ``far'' pointers?

A: See question 19.40d.

----------------------------------------------------------------------------------

Structures, Unions, and Enumerations

----------------------------------------------------------------------------------

  Structures, Unions, and Enumerations

----------------------------------------------------------------------------------

 Question 2.1

Q: What's the difference between these two declarations?
    struct x1 { ... };
    typedef struct { ... } x2;

A: The first form declares a structure tag; the second declares a typedef. The main difference is that the second declaration is of a slightly more abstract type--its users don't necessarily know that it is a structure, and the keyword struct is not used when declaring instances of it:
    x2 b;
Structures declared with tags, on the other hand, must be defined with the
    struct x1 a;
form. [footnote]
(It's also possible to play it both ways:
    typedef struct x3 { ... } x3;
It's legal, if potentially obscure, to use the same name for both the tag and the typedef, since they live in separate namespaces. See question 1.29.)

----------------------------------------------------------------------------------

  Question 2.2

Q: Why doesn't
struct x { ... };
x thestruct;
work?
A: C is not C++. Typedef names are not automatically generated for structure tags. Either declare structure instances using the struct keyword:
    struct x thestruct;
or declare a typedef when you declare a structure:
    typedef struct { ... } x;

    x thestruct;
See also questions 1.14 and 2.1.

----------------------------------------------------------------------------------

Question 2.3

Q: Can a structure contain a pointer to itself?
A: Most certainly. A problem can arise if you try to use typedefs; see questions 1.14 and 1.15.

----------------------------------------------------------------------------------

  Question 2.4

Q: How can I implement opaque (abstract) data types in C?

A: One good way is for clients to use structure pointers (perhaps additionally hidden behind typedefs) which point to structure types which are not publicly defined. In other words, a client uses structure pointers (and calls functions accepting and returning structure pointers) without knowing anything about what the fields of the structure are. (As long as the details of the structure aren't needed--e.g. as long as the -> and sizeof operators are not used--C is perfectly happy to handle pointers to structures of incomplete type.[footnote] ) Only within the source files implementing the abstract data type are complete declarations for the structures actually in scope.
See also question 11.5.

----------------------------------------------------------------------------------

Question 2.4b

Q: Is there a good way of simulating OOP-style inheritance, or other OOP features, in C?
A: It's straightforward to implement simple ``methods'' by placing function pointers in structures. You can make various clumsy, brute-force attempts at inheritance using the preprocessor or by having structures contain ``base types'' as initial subsets, but it won't be perfect. There's obviously no operator overloading, and overriding (i.e. of ``methods'' in ``derived classes'') would have to be done by hand.
Obviously, if you need ``real'' OOP, you'll want to use a language that supports it, such as C++.

----------------------------------------------------------------------------------

  Question 2.5

Q: Why does the declaration
extern int f(struct x *p);
give me an obscure warning message about ``struct x declared inside parameter list''?
A: See question 11.5.

----------------------------------------------------------------------------------

 Question 2.6

Q: I came across some code that declared a structure like this:
struct name {
    int namelen;
    char namestr[1];
};
and then did some tricky allocation to make the namestr array act like it had several elements, with the number recorded by namelen. How does this work? Is it legal or portable?
A: It's not clear if it's legal or portable, but it is rather popular. An implementation of the technique might look something like this:
#include <stdlib.h>
#include <string.h>

struct name *makename(char *newname)
{
    struct name *ret =
        malloc(sizeof(struct name)-1 + strlen(newname)+1);
                /* -1 for initial [1]; +1 for \0 */
    if(ret != NULL) {
        ret->namelen = strlen(newname);
        strcpy(ret->namestr, newname);
    }

    return ret;
}
This function allocates an instance of the name structure with the size adjusted so that the namestr field can hold the requested name (not just one character, as the structure declaration would suggest).
Despite its popularity, the technique is also somewhat notorious: Dennis Ritchie has called it ``unwarranted chumminess with the C implementation,'' and an official interpretation has deemed that it is not strictly conforming with the C Standard, although it does seem to work under all known implementations. (Compilers which check array bounds carefully might issue warnings.)
Another possibility is to declare the variable-size element very large, rather than very small. The above example could be rewritten like this:
#include <stdlib.h>
#include <string.h>

#define MAXSIZE 100

struct name {
    int namelen;
    char namestr[MAXSIZE];
};

struct name *makename(char *newname)
{
    struct name *ret =
        malloc(sizeof(struct name)-MAXSIZE+strlen(newname)+1);
                                /* +1 for \0 */
    if(ret != NULL) {
        ret->namelen = strlen(newname);
        strcpy(ret->namestr, newname);
    }

    return ret;
}
where MAXSIZE is larger than any name which will be stored. However, it looks like this technique is disallowed by a strict interpretation of the Standard as well. Furthermore, either of these ``chummy'' structures must be used with care, since the programmer knows more about their size than the compiler does.
Of course, to be truly safe, the right thing to do is use a character pointer instead of an array:
#include <stdlib.h>
#include <string.h>

struct name {
    int namelen;
    char *namep;
};

struct name *makename(char *newname)
{
    struct name *ret = malloc(sizeof(struct name));
    if(ret != NULL) {
        ret->namelen = strlen(newname);
        ret->namep = malloc(ret->namelen + 1);
        if(ret->namep == NULL) {
            free(ret);
            return NULL;
        }
        strcpy(ret->namep, newname);
    }

    return ret;
}
(Obviously, the ``convenience'' of having the length and the string stored in the same block of memory has now been lost, and freeing instances of this structure will require two calls to free; see question 7.23.)
When the data type being stored is characters, as in the above examples, it is straightforward to coalesce the two calls to malloc into one, to preserve contiguity (and therefore rescue the ability to use a single call to free):
struct name *makename(char *newname)
{
    char *buf = malloc(sizeof(struct name) +
                strlen(newname) + 1);
    struct name *ret = (struct name *)buf;
    ret->namelen = strlen(newname);
    ret->namep = buf + sizeof(struct name);
    strcpy(ret->namep, newname);

    return ret;
}
However, piggybacking a second region onto a single malloc call like this is only portable if the second region is to be treated as an array of char. For any larger type, alignment (see questions 2.12 and 16.7) becomes significant and would have to be preserved.
C99 introduces the concept of a flexible array member, which allows the size of an array to be omitted if it is the last member in a structure, thus providing a well-defined solution.
References: Rationale Sec. 3.5.4.2
C9X Sec. 6.5.2.1

----------------------------------------------------------------------------------

  Question 2.7

Q: I heard that structures could be assigned to variables and passed to and from functions, but K&R1 says not.
A: What K&R1 said (though this was quite some time ago by now) was that the restrictions on structure operations would be lifted in a forthcoming version of the compiler, and in fact the operations of assigning structures, passing structures as function arguments, and returning structures from functions were fully functional in Ritchie's compiler even as K&R1 was being published. A few ancient compilers may have lacked these operations, but all modern compilers support them, and they are part of the ANSI C standard, so there should be no reluctance to use them. [footnote]
(Note that when a structure is assigned, passed, or returned, the copying is done monolithically. This means that the copies of any pointer fields will point to the same place as the original. In other words, the data pointed to is not copied.)
See the code fragments in question 14.11 for an example of structure operations in action.

----------------------------------------------------------------------------------

Question 2.8

Q: Is there a way to compare structures automatically?
A: No. There is not a good way for a compiler to implement structure comparison (i.e. to support the == operator for structures) which is consistent with C's low-level flavor. A simple byte-by-byte comparison could founder on random bits present in unused ``holes'' in the structure (such padding is used to keep the alignment of later fields correct; see question 2.12). A field-by-field comparison might require unacceptable amounts of repetitive code for large structures. Any compiler-generated comparison could not be expected to compare pointer fields appropriately in all cases: for example, it's often appropriate to compare char * fields with strcmp rather than == (see also question 8.2).
If you need to compare two structures, you'll have to write your own function to do so, field by field.

----------------------------------------------------------------------------------

  Question 2.9

Q: How are structure passing and returning implemented?
A: When structures are passed as arguments to functions, the entire structure is typically pushed on the stack, using as many words as are required. (Programmers often choose to use pointers to structures instead, precisely to avoid this overhead.) Some compilers merely pass a pointer to the structure, though they may have to make a local copy to preserve pass-by-value semantics.
Structures are often returned from functions in a location pointed to by an extra, compiler-supplied ``hidden'' argument to the function. Some older compilers used a special, static location for structure returns, although this made structure-valued functions non-reentrant, which ANSI C disallows.

----------------------------------------------------------------------------------

  Question 2.10

Q: How can I pass constant values to functions which accept structure arguments? How can I create nameless, immediate, constant structure values?
A: Traditional C had no way of generating anonymous structure values; you had to use a temporary structure variable or a little structure-building function; see question 14.11 for an example.
C99 introduces ``compound literals'', one form of which provides for structure constants. For example, to pass a constant coordinate pair to a hypothetical plotpoint function which expects a struct point, you can call
    plotpoint((struct point){1, 2});
Combined with ``designated initializers'' (another C99 feature), it is also possible to specify member values by name:
    plotpoint((struct point){.x=1, .y=2});

----------------------------------------------------------------------------------

 Question 2.11

Q: How can I read/write structures from/to data files?
A: It is relatively straightforward to write a structure out using fwrite:
    fwrite(&somestruct, sizeof somestruct, 1, fp);
and a corresponding fread invocation can read it back in. What happens here is that fwrite receives a pointer to the structure, and writes (or fread correspondingly reads) the memory image of the structure as a stream of bytes. The sizeof operator determines how many bytes the structure occupies.
(The call to fwrite above is correct under an ANSI compiler as long as a prototype for fwrite is in scope, usually because <stdio.h> is #included.
However, data files written as memory images in this way will not be portable, particularly if they contain floating-point fields or pointers. The memory layout of structures is machine and compiler dependent. Different compilers may use different amounts of padding (see question 2.12), and the sizes and byte orders of fundamental types vary across machines. Therefore, structures written as memory images cannot necessarily be read back in by programs running on other machines (or even compiled by other compilers), and this is an important concern if the data files you're writing will ever be interchanged between machines. See also questions 2.12 and 20.5.
Also, if the structure contains any pointers (char * strings, or pointers to other data structures), only the pointer values will be written, and they are most unlikely to be valid when read back in. Finally, note that for widespread portability you must use the "b" flag when opening the files; see question 12.38.
A more portable solution, though it's a bit more work initially, is to write a pair of functions for writing and reading a structure, field-by-field, in a portable (perhaps even human-readable) way.
References: H&S Sec. 15.13 p. 381

----------------------------------------------------------------------------------

Question 2.12

Q: Why is my compiler leaving holes in structures, wasting space and preventing ``binary'' I/O to external data files? Can I turn this off, or otherwise control the alignment of structure fields?
A: Many machines access values in memory most efficiently when the values are appropriately aligned. (For example, on a byte-addressed machine, short ints of size 2 might best be placed at even addresses, and long ints of size 4 at addresses which are a multiple of 4.) Some machines cannot perform unaligned accesses at all, and require that all data be appropriately aligned.
Therefore, if you declare a structure like
    struct {
        char c;
        int i;
    };
the compiler will usually leave an unnamed, unused hole between the char and int fields, to ensure that the int field is properly aligned. (This incremental alignment of the second field based on the first relies on the fact that the structure itself is always properly aligned, with the most conservative alignment requirement. The compiler guarantees this alignment for structures it allocates, as does malloc.)
Your compiler may provide an extension to give you control over the packing of structures (i.e. whether they are padded or not), perhaps with a #pragma (see question 11.20), but there is no standard method.
If you're worried about wasted space, you can minimize the effects of padding by ordering the members of a structure based on their base types, from largest to smallest. You can sometimes get more control over size and alignment by using bit-fields, although they have their own drawbacks. (See question 2.26.)
See also questions 2.13, 16.7, and 20.5.

----------------------------------------------------------------------------------

  Question 2.13

Q: Why does sizeof report a larger size than I expect for a structure type, as if there were padding at the end?
A: Padding at the end of a structure may be necessary to preserve alignment when an array of contiguous structures is allocated. Even when the structure is not part of an array, the padding remains, so that sizeof can always return a consistent size. See also question 2.12.

----------------------------------------------------------------------------------

  Question 2.14

Q: How can I determine the byte offset of a field within a structure?
A: ANSI C defines the offsetof() macro in <stddef.h>, which lets you compute the offset of field f in struct s as offsetof(struct s, f). If for some reason you have to code this sort of thing yourself, one possibility is
    #define offsetof(type, f) ((size_t) \
        ((char *)&((type *)0)->f - (char *)(type *)0))
This implementation is not 100% portable; some compilers may legitimately refuse to accept it.
(The complexities of the definition above bear a bit of explanation. The subtraction of a carefully converted null pointer is supposed to guarantee that a simple offset is computed even if the internal representation of the null pointer is not 0. The casts to (char *) arrange that the offset so computed is a byte offset. The nonportability is in pretending, if only for the purposes of address calculation, that there is an instance of the type sitting at address 0. Note, however, that since the pretend instance is not actually referenced, an access violation is unlikely.)

----------------------------------------------------------------------------------

  Question 2.15

Q: How can I access structure fields by name at run time?
A: Keep track of the field offsets as computed using the offsetof() macro (see question 2.14). If structp is a pointer to an instance of the structure, and field f is an int having offset offsetf, f's value can be set indirectly with
    *(int *)((char *)structp + offsetf) = value;

----------------------------------------------------------------------------------

 Question 2.16

Q: Does C have an equivalent to Pascal's with statement?
A: See question 20.23.

----------------------------------------------------------------------------------

Question 2.17

Q: If an array name acts like a pointer to the base of an array, why isn't the same thing true of a structure?
A: The rule (see question 6.3) that causes array references to ``decay'' into pointers is a special case which applies only to arrays, and reflects their ``second class'' status in C. (An analogous rule applies to functions.) Structures, however, are first class objects: when you mention a structure, you get the entire structure.

----------------------------------------------------------------------------------

  Question 2.18

Q: This program works correctly, but it dumps core after it finishes. Why?
    struct list {
        char *item;
        struct list *next;
    }

    /* Here is the main program. */

    main(argc, argv)
    { ... }

A: A missing semicolon at the end of the structure declaration causes main to be declared as returning a structure. (The connection is hard to see because of the intervening comment.) Since structure-valued functions are usually implemented by adding a hidden return pointer (see question 2.9), the generated code for main() tries to accept three arguments, although only two are passed (in this case, by the C start-up code).

----------------------------------------------------------------------------------

Question 2.19

Q: What's the difference between a structure and a union, anyway?
A: A union is essentially a structure in which all of the fields overlay each other; you can only use one field at a time. (You can also cheat by writing to one field and reading from another, to inspect a type's bit patterns or interpret them differently, but that's obviously pretty machine-dependent.) The size of a union is the maximum of the sizes of its individual members, while the size of a structure is the sum of the sizes of its members. (In both cases, the size may be increased by padding; see questions 2.12 and 2.13.)
References: ISO Sec. 6.5.2.1
H&S Sec. 5.7 pp. 140-145 esp. Sec. 5.7.4

----------------------------------------------------------------------------------

  Question 2.20

Q: Can I initialize unions?
A: In the original ANSI C, an initializer was allowed only for the first-named member of a union. C99 introduces ``designated initializers'' which can be used to initialize any member.
In the absence of designated initializers, if you're desperate, you can sometimes define several variant copies of a union, with the members in different orders, so that you can declare and initialize the one having the appropriate first member. (These variants are guaranteed to be implemented compatibly, so it's okay to ``pun'' them by initializing one and then using the other.)
References: K&R2 Sec. 6.8 pp. 148-9
ISO Sec. 6.5.7
C9X Sec. 6.5.8
H&S Sec. 4.6.7 p. 100

----------------------------------------------------------------------------------

 Question 2.21

Q: Is there an automatic way to keep track of which field of a union is in use?
A: No. You can implement an explicitly ``tagged'' union yourself:
struct taggedunion {
    enum {UNKNOWN, INT, LONG, DOUBLE, POINTER} code;
    union {
        int i;
        long l;
        double d;
        void *p;
    } u;
};
You will have to make sure that the code field is always set appropriately when the union is written to; the compiler won't do any of this for you automatically. (C unions are not like Pascal variant records.)

----------------------------------------------------------------------------------

  Question 2.22

Q: What's the difference between an enumeration and a set of preprocessor #defines?
A: There is little difference. The C Standard says that enumerations have integral type and that enumeration constants are of type int, so both may be freely intermixed with other integral types, without errors. (If, on the other hand, such intermixing were disallowed without explicit casts, judicious use of enumerations could catch certain programming errors.)
Some advantages of enumerations are that the numeric values are automatically assigned, that a debugger may be able to display the symbolic values when enumeration variables are examined, and that they obey block scope. (A compiler may also generate nonfatal warnings when enumerations are indiscriminately mixed, since doing so can still be considered bad style even though it is not strictly illegal.) A disadvantage is that the programmer has little control over those nonfatal warnings; some programmers also resent not having control over the sizes of enumeration variables.

----------------------------------------------------------------------------------

  Question 2.23

Q: Are enumerations really portable?
Aren't they Pascalish?
A: Enumerations were a mildly late addition to the language (they were not in K&R1), but they are definitely part of the language now: they're in the C Standard, and all modern compilers support them. They're quite portable, although historical uncertainty about their precise definition led to their specification in the Standard being rather weak (see question 2.22).

----------------------------------------------------------------------------------

 Question 2.24

Q: Is there an easy way to print enumeration values symbolically?
A: No. You can write a little function (one per enumeration) to map an enumeration constant to a string, either by using a switch statement or by searching an array. (For debugging purposes, a good debugger should automatically print enumeration constants symbolically.)

----------------------------------------------------------------------------------

  Question 2.25

Q: I came across some structure declarations with colons and numbers next to certain fields, like this:
struct record {
    char *name;
    int refcount : 4;
    unsigned dirty : 1;
};
What gives?

A: Those are bit-fields; the number gives the exact size of the field, in bits. (See any complete book on C for the details.) Bit-fields can be used to save space in structures having several binary flags or other small fields, and they can also be used in an attempt to conform to externally-imposed storage layouts. (Their success at the latter task is mitigated by the fact that bit-fields are assigned left-to-right on some machines and right-to-left on others).
Note that the colon notation for specifying the size of a field in bits is only valid in structures (and in unions); you cannot use this mechanism to specify the size of arbitrary variables. (See questions 1.2 and 1.3.)

----------------------------------------------------------------------------------

  Question 2.26

Q: Why do people use explicit masks and bit-twiddling code so much, instead of declaring bit-fields?
A: Bit-fields are thought to be nonportable, although they are no less portable than other parts of the language. (You don't know how big they can be, but that's equally true for values of type int. You don't know by default whether they're signed, but that's equally true of type char. You don't know whether they're laid out from left to right or right to left in memory, but that's equally true of the bytes of all types, and only matters if you're trying to conform to externally-imposed storage layouts, which is always nonportable; see also questions 2.12 and 20.5.)
Bit-fields are inconvenient when you also want to be able to manipulate some collection of bits as a whole (perhaps to copy a set of flags). You can't have arrays of bit-fields; see also question 20.8. Many programmers suspect that the compiler won't generate good code for bit-fields (historically, this was sometimes true).
Straightforward code using bit-fields is certainly clearer than the equivalent explicit masking instructions; it's too bad that bit-fields can't be used more often.

----------------------------------------------------------------------------------

Declarations and Initializations

----------------------------------------------------------------------------------

                         Declarations and Initializations

----------------------------------------------------------------------------------

 

Question 1.1

Q: How should I decide which integer type to use?
A: If you might need large values (above 32,767 or below -32,767), use long. Otherwise, if space is very important (i.e. if there are large arrays or many structures), use short. Otherwise, use int. If well-defined overflow characteristics are important and negative values are not, or if you want to steer clear of sign-extension problems when manipulating bits or bytes, use one of the corresponding unsigned types. (Beware when mixing signed and unsigned values in expressions, though; see question 3.19.)
Although character types (especially unsigned char) can be used as ``tiny'' integers, doing so is sometimes more trouble than it's worth. The compiler will have to emit extra code to convert between char and int (making the executable larger), and unexpected sign extension can be troublesome. (Using unsigned char can help; see question 12.1 for a related problem.)
A similar space/time tradeoff applies when deciding between float and double. (Many compilers still convert all float values to double during expression evaluation.) None of the above rules apply if pointers to the variable must have a particular type.
Variables referring to certain kinds of data, such as sizes of objects in memory, can and should used predefined abstract types such as size_t.
It's often incorrectly assumed that C's types are defined to have certain, exact sizes. In fact, what's guaranteed is that:
type char can hold values up to 127;
types short int and int can hold values up to 32,767; and
type long int can hold values up to 2,147,483,647.
something like the relation
    sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)
holds.
From these values, it can be inferred that char is at least 8 bits, short int and int are at least 16 bits, and long int is at least 32 bits. (The signed and unsigned versions of each type are guaranteed to have the same size.) Under ANSI C, the maximum and minimum values for a particular machine can be found in the header file <limits.h>; here is a summary:

Base type    Minimum size (bits)    Minimum value (signed)    Maximum value (signed)    Maximum value (unsigned)     
char    8    -127    127    255     
short    16    -32,767    32,767    65,535     
int    16    -32,767    32,767    65,535     
long    32    -2,147,483,647    2,147,483,647    4,294,967,295    
(These values are the minimums guaranteed by the Standard. Many implementations allow larger values, but portable programs shouldn't depend on it.)
If for some reason you need to declare something with an exact size (usually the only good reason for doing so is when attempting to conform to some externally-imposed storage layout, but see question 20.5), be sure to encapsulate the choice behind an appropriate typedef, but see question 1.3.
If you need to manipulate huge values, larger than the guaranteed range of C's built-in types, you need an arbitrary-precision (or ``multiple precision'') arithmetic library; see question 18.15d.
References: K&R1 Sec. 2.2 p. 34
K&R2 Sec. 2.2 p. 36, Sec. A4.2 pp. 195-6, Sec. B11 p. 257
ISO Sec. 5.2.4.2.1, Sec. 6.1.2.5
H&S Secs. 5.1,5.2 pp. 110-114

----------------------------------------------------------------------------------

 Question 1.2

Q: Why aren't the sizes of the standard types precisely defined?
A: Though C is considered relatively low-level as high-level languages go, it does take the position that the exact size of an object (i.e. in bits) is an implementation detail. (The only place where C lets you specify a size in bits is in bit-fields within structures; see questions 2.25 and 2.26.) Most programs do not need precise control over these sizes; many programs that do try to achieve this control would be better off if they didn't.
Type int is supposed to represent a machine's natural word size. It's the right type to use for most integer variables; see question 1.1 for other guidelines. See also questions 12.42 and 20.5.

----------------------------------------------------------------------------------

 Question 1.3

Q: Since C doesn't define sizes exactly, I've been using typedefs like int16 and int32. I can then define these typedefs to be int, short, long, etc. depending on what machine I'm using. That should solve everything, right?
A: If you truly need control over exact type sizes, this is the right approach. There remain several things to be aware of:
There might not be an exact match on some machines. (There are, for example, 36-bit machines.)
A typedef like int16 or int32 accomplishes nothing if its intended meaning is ``at least'' the specified size, because types int and long are already essentially defined as being ``at least 16 bits'' and ``at least 32 bits,'' respectively.
Typedefs will never do anything about byte order problems (e.g. if you're trying to interchange data or conform to externally-imposed storage layouts).
You no longer have to define your own typedefs, because the Standard header <inttypes.h> contains a complete set.
See also questions 10.16 and 20.5.

----------------------------------------------------------------------------------

 Question 1.4

Q: What should the 64-bit type be on a machine that can support it?
A: The new C99 Standard specifies type long long as effectively being at least 64 bits, and this type has been implemented by a number of compilers for some time. (Others have implemented extensions such as __longlong.) On the other hand, it's also appropriate to implement type short int as 16, int as 32, and long int as 64 bits, and some compilers do.
See also questions 1.3 and 18.15d.
Additional links: Part of a proposal for long long for C9X by Alan Watson and Jutta Degener, succinctly outlining the arguments.

----------------------------------------------------------------------------------

 Question 1.5

Q: What's wrong with this declaration?
char* p1, p2;
I get errors when I try to use p2.
A: Nothing is wrong with the declaration--except that it doesn't do what you probably want. The * in a pointer declaration is not part of the base type; it is part of the declarator containing the name being declared (see question 1.21). That is, in C, the syntax and interpretation of a declaration is not really
    type identifier ;
but rather
    base_type thing_that_gives_base_type ;
where ``thing_that_gives_base_type''--the declarator--is either a simple identifier, or a notation like *p or a[10] or f() indicating that the variable being declared is a pointer to, array of, or function returning that base_type. (Of course, more complicated declarators are possible as well.)
In the declaration as written in the question, no matter what the whitespace suggests, the base type is char and the first declarator is ``* p1'', and since the declarator contains a *, it declares p1 as a pointer-to-char. The declarator for p2, however, contains nothing but p2, so p2 is declared as a plain char, probably not what was intended. To declare two pointers within the same declaration, use
    char *p1, *p2;
Since the * is part of the declarator, it's best to use whitespace as shown; writing char* invites mistakes and confusion.
See also question 1.13.

----------------------------------------------------------------------------------

 Question 1.6

Q: I'm trying to declare a pointer and allocate some space for it, but it's not working. What's wrong with this code?
char *p;
*p = malloc(10);
A: The pointer you declared is p, not *p. See question 4.2.

----------------------------------------------------------------------------------

 Question 1.7

Q: What's the best way to declare and define global variables and functions?
A: First, though there can be many declarations (and in many translation units) of a single global variable or function, there must be exactly one definition. For global variables, the definition is the declaration that actually allocates space, and provides an initialization value, if any. For functions, the definition is the ``declaration'' that provides the function body. For example, these are declarations:
    extern int i;

    extern int f();
and these are definitions:
    int i = 0;

    int f()
    {
        return 1;
    }
(Actually, the keyword extern is optional in function declarations; see question 1.11.)
When you need to share variables or functions across several source files, you will of course want to ensure that all definitions and declarations are consistent. The best arrangement is to place each definition in some relevant .c file. Then, put an external declaration in a header (``.h'') file, and #include it wherever the declaration is needed. The .c file containing the definition should also #include the same header file, so the compiler can check that the definition matches the declarations.
This rule promotes a high degree of portability: it is consistent with the requirements of the ANSI C Standard, and is also consistent with most pre-ANSI compilers and linkers. (Unix compilers and linkers typically use a ``common model'' which allows multiple definitions, as long as at most one is initialized; this behavior is mentioned as a ``common extension'' by the ANSI Standard, no pun intended. A few very old systems might once have required an explicit initializer to distinguish a definition from an external declaration.)
It is possible to use preprocessor tricks to arrange that a line like
    DEFINE(int, i);
need only be entered once in one header file, and turned into a definition or a declaration depending on the setting of some macro, but it's not clear if this is worth the trouble, especially since it's usually a better idea to keep global variables to a minimum.
It's not just a good idea to put global declarations in header files: if you want the compiler to be able to catch inconsistent declarations for you, you must place them in header files. In particular, never place a prototype for an external function in a .c file--if the definition of the function ever changes, it would be too easy to forget to change the prototype, and an incompatible prototype is worse than useless.
See also questions 1.24, 10.6, 17.2, and 18.8.

----------------------------------------------------------------------------------

 Question 1.8

Q: How can I implement opaque (abstract) data types in C?
A: See question 2.4.

----------------------------------------------------------------------------------

 Question 1.9

Q: How can I make a sort of ``semi-global'' variable, that is, one that's private to a few functions spread across a few source files?
A: You can't do this in C. If it's impossible or inconvenient to put all the functions in the same source file, there are two usual solutions:
Pick a unique prefix for the names of all functions and global variables in a library or package of related routines, and warn users of the package not to define or use any symbols with names matching that prefix other than those documented as being for public consumption. (In other words, an undocumented but otherwise global symbol with a name matching that prefix is, by convention, ``private.'')
Use a name beginning with an underscore, since such names shouldn't be used by ordinary code. (See question 1.29 for more information, and for a description of the ``no man's land'' between the user and implementation namespaces.)
It may also be possible to use special linker invocations to adjust the visibility of names, but any such techniques are outside of the scope of the C language.

----------------------------------------------------------------------------------

 Question 1.10

Q: Do all declarations for the same static function or variable have to include the storage class static?
A: The language in the Standard does not quite require this (what's most important is that the first declaration contain static), but the rules are rather intricate, and are slightly different for functions than for data objects. (There has also been a lot of historical variation in this area.) Therefore, it's safest if static appears consistently in the definition and all declarations.
Additional links: An article by Jutta Degener explaining the subtly different rules for static variables versus static functions.

----------------------------------------------------------------------------------

 Question 1.11

Q: What does extern mean in a function declaration?
A: extern is significant only with data declarations. In function declarations, it can be used as a stylistic hint to indicate that the function's definition is probably in another source file, but there is no formal difference between
    extern int f();
and
    int f();
See also question 1.10.

----------------------------------------------------------------------------------

 Question 1.12

Q: What's the auto keyword good for?
A: Nothing; it's archaic. (It's a holdover from C's typeless predecessor language B, where in the absence of keywords like int a declaration always needed a storage class.) See also question 20.37.
References: K&R1 Sec. A8.1 p. 193
ISO Sec. 6.1.2.4, Sec. 6.5.1
H&S Sec. 4.3 p. 75, Sec. 4.3.1 p. 76

 Question 1.13
Q: What's the difference between using a typedef or a #define for a user-defined type?
A: In general, typedefs are preferred, in part because they can correctly encode pointer types. For example, consider these declarations:
    typedef char *String_t;
    #define String_d char *
    String_t s1, s2;
    String_d s3, s4;
s1, s2, and s3 are all declared as char *, but s4 is declared as a char, which is probably not the intention. (See also question 1.5.)
#defines do have the advantage that #ifdef works on them (see also question 10.15). On the other hand, typedefs have the advantage that they obey scope rules (that is, they can be declared local to a function or block).

----------------------------------------------------------------------------------

 Question 1.14

Q: I can't seem to define a linked list successfully. I tried
    typedef struct {
        char *item;
        NODEPTR next;
    } *NODEPTR;
but the compiler gave me error messages. Can't a structure in C contain a pointer to itself?
A: Structures in C can certainly contain pointers to themselves; the discussion and example in section 6.5 of K&R make this clear.
The problem with this example is the typedef. A typedef defines a new name for a type, and in simpler cases you can define a new structure type and a typedef for it at the same time, but not in this case. A typedef declaration can not be used until it is defined, and in the fragment above, it is not yet defined at the point where the next field is declared.
To fix this code, first give the structure a tag (e.g. ``struct node''). Then, declare the next field as a simple struct node *, or disentangle the typedef declaration from the structure definition, or both. One corrected version would be:
    typedef struct node {
        char *item;
        struct node *next;
    } *NODEPTR;
You could also precede the struct declaration with the typedef, in which case you could use the NODEPTR typedef when declaring the next field, after all:
    typedef struct node *NODEPTR;

    struct node {
        char *item;
        NODEPTR next;
    };
(In this case, you declare a new tyedef name involving struct node even though struct node has not been completely defined yet; this you're allowed to do.)
Finally, here is a rearrangement incorporating both suggestions:
    struct node {
        char *item;
        struct node *next;
    };

    typedef struct node *NODEPTR;

----------------------------------------------------------------------------------

 Question 1.15

Q: How can I define a pair of mutually referential structures? I tried
    typedef struct {
        int afield;
        BPTR bpointer;
    } *APTR;

    typedef struct {
        int bfield;
        APTR apointer;
    } *BPTR;
but the compiler doesn't know about BPTR when it is used in the first structure declaration.
A: As in question 1.14, the problem lies not in the structures or the pointers but the typedefs. First, give the two structures tags, and define the link pointers without using typedefs:
    struct a {
        int afield;
        struct b *bpointer;
    };

    struct b {
        int bfield;
        struct a *apointer;
    };
The compiler can accept the field declaration struct b *bpointer within struct a, even though it has not yet heard of struct b. (struct b is ``incomplete'' at that point.) Occasionally it is necessary to precede this couplet with the empty declaration
    struct b;
to mask the declarations (if in an inner scope) from a different struct b in an outer scope.
After declaring the two structures using struct tags, you can then declare the typedefs separately:
    typedef struct a *APTR;
    typedef struct b *BPTR;
Alternatively, you can define the typedefs before the struct definitions, in which case you can use them when declaring the link pointer fields:
    typedef struct a *APTR;
    typedef struct b *BPTR;

    struct a {
        int afield;
        BPTR bpointer;
    };

    struct b {
        int bfield;
        APTR apointer;
    };

----------------------------------------------------------------------------------

 Question 1.16

Q: What's the difference between these two declarations?
    struct x1 { ... };
    typedef struct { ... } x2;
A: See question 2.1.

 Question 1.17

Q: What does
typedef int (*funcptr)();
mean?
A: It defines a typedef, funcptr, for a pointer to a function (taking unspecified arguments) returning an int. It can be used to declare one or more pointers to functions:
    funcptr pf1, pf2;
which is equivalent to the more verbose, and perhaps harder to understand
    int (*pf1)(), (*pf2)();
See also questions 1.21, 4.12, and 15.11.

----------------------------------------------------------------------------------

 Question 1.18

Q: I've got the declarations
    typedef char *charp;
    const charp p;
Why is p turning out const, instead of the characters pointed to?
A: See question 11.11.

----------------------------------------------------------------------------------

 Question 1.19

Q: I don't understand why I can't use const values in initializers and array dimensions, as in
    const int n = 5;
    int a[n];
A: See question 11.8.

----------------------------------------------------------------------------------

 Question 1.20

Q: What's the difference between const char *p, char const *p, and char * const p?
A: See questions 11.9 and 1.21.

----------------------------------------------------------------------------------

 Question 1.20b

Q: What does it mean for a function parameter to be const? What do the two const's in
    int f(const * const p)
mean?
A: In
    int f(const * const p)
the first of the two const's is perfectly appropriate and quite useful; many functions declare parameters which are pointers to const data, and doing so documents (and tends to enforce) the function's promise that it won't modify the pointed-to data in the caller. The second const, on the other hand, is almost useless; all it says is that the function won't alter its own copy of the pointer, even though it wouldn't cause the caller or the function any problems if it did, nor is this anything the caller should care about in any case. The situation is the same as if a function declared an ordinary (non-pointer) parameter as const:
    int f2(const int x)
This says that nowhere in the body of f2() will the function assign a different value to x. (Compilers should try to enforce this promise, too.) But assigning a different value to x wouldn't affect the value that the caller had passed (because C always uses call-by-value), so it's an unimportant guarantee, and in fact a pretty useless one, because what does the function gain by promising (to itself, since it's the only one that could care) whether it will or won't be modifying in the passed-in copy of the value?

----------------------------------------------------------------------------------

 Question 1.21

Q: How do I construct declarations of complicated types such as ``array of N pointers to functions returning pointers to functions returning pointers to char'', or figure out what similarly complicated declarations mean?

A: The first part of this question can be answered in at least three ways:
char *(*(*a[N])())();
Build the declaration up incrementally, using typedefs:
    typedef char *pc;    /* pointer to char */
    typedef pc fpc();    /* function returning pointer to char */
    typedef fpc *pfpc;    /* pointer to above */
    typedef pfpc fpfpc();    /* function returning... */
    typedef fpfpc *pfpfpc;    /* pointer to... */
    pfpfpc a[N];        /* array of... */
Use the cdecl program, which turns English into C and vice versa. You provide a longhand description of the type you want, and cdecl responds with the equivalent C declaration:
    cdecl> declare a as array of pointer to function returning
        pointer to function returning pointer to char

    char *(*(*a[])())()
cdecl can also explain complicated declarations (you give it a complicated declaration and it responds with an English description), help with casts, and indicate which set of parentheses the parameters go in (for complicated function definitions, like the one above). See question 18.1.
C's declarations can be confusing because they come in two parts: a base type, and a declarator which contains the identifier or name being declared, perhaps along with *'s and []'s and ()'s saying whether the name is a pointer to, array of, or function returning the base type, or some combination.For example, in
    char *pc;
the base type is char, the identifier is pc, and the declarator is *pc; this tells us that *pc is a char (this is what ``declaration mimics use'' means).
One way to make sense of complicated C declarations is by reading them ``inside out,'' remembering that [] and () bind more tightly than *. For example, given
    char *(*pfpc)();
we can see that pfpc is a pointer (the inner *) to a function (the ()) to a pointer (the outer *) to char. When we later use pfpc, the expression *(*pfpc)() (the value pointed to by the return value of a function pointed to by pfpc) will be a char.
Another way of analyzing these declarations is to decompose the declarator while composing the description, maintaining the ``declaration mimics use'' relationship:

    *(*pfpc)()    is a    char
    (*pfpc)()    is a    pointer to char
    (*pfpc)    is a    function returning pointer to char
    pfpc    is a    pointer to function returning pointer to char
If you'd like to make things clearer when declaring complicated types like these, you can make the analysis explicit by using a chain of typedefs as in option 2 above.
The pointer-to-function declarations in the examples above have not included parameter type information. When the parameters have complicated types, declarations can really get messy. (Modern versions of cdecl can help here, too.)
Additional links:

A message of mine explaining the difference between array-of-pointer vs. pointer-to-array declarations

----------------------------------------------------------------------------------

 Question 1.22

Q: How can I declare a function that can return a pointer to a function of the same type? I'm building a state machine with one function for each state, each of which returns a pointer to the function for the next state. But I can't find a way to declare the functions--I seem to need a function returning a pointer to a function returning a pointer to a function returning a pointer to a function..., ad infinitum.
A: You can't quite do it directly. One way is to have the function return a generic function pointer (see question 4.13), with some judicious casts to adjust the types as the pointers are passed around:
typedef int (*funcptr)();      /* generic function pointer */
typedef funcptr (*ptrfuncptr)();  /* ptr to fcn returning g.f.p. */

funcptr start(), stop();
funcptr state1(), state2(), state3();

void statemachine()
{
    ptrfuncptr state = start;

    while(state != stop)
        state = (ptrfuncptr)(*state)();
}

funcptr start()
{
    return (funcptr)state1;
}
(The second ptrfuncptr typedef hides some particularly dark syntax; without it, the state variable would have to be declared as funcptr (*state)() and the call would contain a bewildering cast of the form (funcptr (*)())(*state)().)
Another way (sugested by Paul Eggert, Eugene Ressler, Chris Volpe, and perhaps others) is to have each function return a structure containing only a pointer to a function returning that structure:
struct functhunk {
    struct functhunk (*func)();
};

struct functhunk start(), stop();
struct functhunk state1(), state2(), state3();

void statemachine()
{
    struct functhunk state = {start};

    while(state.func != stop)
        state = (*state.func)();
}

struct functhunk start()
{
    struct functhunk ret;
    ret.func = state1;
    return ret;
}
(Note that these examples use the older, explicit style of calling via function pointers; see question 4.12. See also question 1.17.)

----------------------------------------------------------------------------------

 Question 1.23

Q: Can I declare a local array (or parameter array) of a size matching a passed-in array, or set by another parameter?

A: Historically, you couldn't, but in C99 (and in some pre-C99 compilers with extensions) you can. See questions 6.15 and 6.19.

----------------------------------------------------------------------------------

 Question 1.24

Q: I have an extern array which is defined in one file, and used in another:
file1.c:            file2.c:

int array[] = {1, 2, 3};    extern int array[];
Why doesn't sizeof work on array in file2.c?
A: An extern array of unspecified size is an incomplete type; you cannot apply sizeof to it. sizeof operates at compile time, and there is no way for it to learn the size of an array which is defined in another file.
You have three options:
Declare a companion variable, containing the size of the array, defined and initialized (with sizeof) in the same source file where the array is defined:
file1.c:            file2.c:

int array[] = {1, 2, 3};    extern int array[];
int arraysz = sizeof(array);    extern int arraysz;
(See also question 6.23.)
#define a manifest constant for the size so that it can be used consistently in the definition and the extern declaration:
file1.h:

#define ARRAYSZ 3
extern int array[ARRAYSZ];

file1.c:            file2.c:

#include "file1.h"        #include "file1.h"
int array[ARRAYSZ];
Use some sentinel value (typically 0, -1, or NULL) in the array's last element, so that code can determine the end without an explicit size indication:
file1.c:            file2.c:

int array[] = {1, 2, 3, -1};    extern int array[];

----------------------------------------------------------------------------------

 Question 1.25

Q: My compiler is complaining about an invalid redeclaration of a function, but I only define it once and call it once.
A: Functions which are called without a declaration in scope, perhaps because the first call precedes the function's definition, are assumed to be declared as if by:
    extern int f();
That is, an undeclared function is assumed to return int, and to accept an unspecified number of arguments (though there must be a fixed number of them and none may be ``narrow''). If the function is later defined otherwise, the compiler complains about the discrepancy. Functions returning other than int, or accepting any ``narrow'' arguments, or accepting a variable number of arguments, must all be declared before they are called. (And it's by all means safest to declare all functions, so that function prototypes can check that arguments are passed correctly.)
Another possible source of this problem is that the function has the same name as another one declared in some header file.

----------------------------------------------------------------------------------

 Question 1.25b

Q: What's the right declaration for main?
Is void main() correct?
A: See questions 11.12a through 11.15. (But no, it's not correct.)

----------------------------------------------------------------------------------

 Question 1.26

Q: My compiler is complaining about mismatched function prototypes which look fine to me.
A: See question 11.3.

----------------------------------------------------------------------------------

 Question 1.27

Q: I'm getting strange syntax errors on the very first declaration in a file, but it looks fine.
A: See question 10.9.

----------------------------------------------------------------------------------

 Question 1.28

Q: My compiler isn't letting me declare a big array like
double array[256][256];
A: See question 19.23, and maybe 7.16.

----------------------------------------------------------------------------------

 Question 1.29

Q: How can I determine which identifiers are safe for me to use and which are reserved?
A: Namespace management can be a sticky issue. The problem--which isn't always obvious--is that you don't want to pick identifiers already in use by the implementation, such that you get ``multiply defined'' errors or--even worse--quietly replace one of the implementation's symbols and break everything. You also want some guarantee that later releases won't usurp names you're legitimately using. (Few things are more frustrating than taking a debugged, working, production program, recompiling it under a new release of a compiler, and having the build fail due to namespace or other problems.) Therefore, the ANSI/ISO C Standard contains rather elaborate definitions carving out distinct namespace subsets for the user and the implementation.
To make sense of ANSI's rules, and before we can say whether a given identifier is reserved, we must understand three attributes of the identifier: its scope, namespace, and linkage.
There are four kinds of scope (regions over which an identifier's declaration is in effect) in C: function, file, block, and prototype. (The fourth one exists only in the parameter lists of function prototype declarations; see also question 11.5.)
There are four different kinds of namespaces, for:
labels (i.e. goto targets);
tags (names of structures, unions, and enumerations; these three aren't separate even though they theoretically could be);
structure/union members (one namespace per structure or union); and
everything else (functions, variables, typedef names, enumeration constants), termed ``ordinary identifiers'' by the Standard.
Another set of names (though not termed a ``namespace'' by the Standard) consists of preprocessor macros; these are all expanded before the compiler gets around to considering the four formal namespaces.
The standard defines three kinds of ``linkage'': external, internal, and none. For our purposes, external linkage means global, non-static variables and functions (across all source files), internal linkage means static variables and functions with file scope, and ``no linkage'' refers to local variables, and also things like typedef names and enumeration constants.
The rules, paraphrased from ANSI Sec. 4.1.2.1, are:
1. All identifiers beginning with an underscore followed by an upper-case letter or another underscore are always reserved (all scopes, all namespaces).
2. All identifiers beginning with an underscore are reserved for ordinary identifiers (functions, variables, typedefs, enumeration constants) with file scope.
3. A macro name defined in a standard header is reserved for any use if any header which #defines it is #included.
4. All standard library identifiers with external linkage (e.g. function names) are always reserved as identifiers with external linkage.
5. Typedef and tag names, with file scope, defined in standard headers, are reserved at file scope (in the same namespace) if the corresponding header is #included. (The Standard really says ``each identifier with file scope,'' but the only standard identifiers not covered by rule 4 are typedef and tag names.)
Rules 3 and 4 are additionally complicated by the fact that several sets of macro names and standard library identifiers are reserved for ``future directions'' that is, later revisions of the Standard may define new names matching certain patterns.
Here is a list of the patterns which are reserved for ``future directions'' associared with each standard header:
[TABLE GOES HERE]
(The notation [A-Z] means ``any uppercase letter''; similarly, [a-z] and [0-9] indicate lower-case letters and digits. The notation * means ``anything.'' For example, the pattern for <stdlib.h> says that all external identifiers beginning with the letters str followed by a lower-case letter are reserved.)
What do the above rules really mean? If you want to be on the safe side:
1,2. Don't give anything a name with a leading underscore.
3. Don't give anything a name which is already a standard macro (including the ``future directions'' patterns).
4. Don't give any functions or global variables names which are already taken by functions or variables in the standard library, or which match any of the ``future directions'' patterns. (Strictly speaking, ``matching'' means matching in the first six characters, without regard to case; see question 11.27.)
5. Don't redefine standard typedef or tag names.
In fact, the preceding subparagraphs are overly conservative. If you wish, you may remember the following exceptions:
1,2. You may use identifiers consisting of an underscore followed by a digit or lower case letter for labels and structure/union members.
1,2. You may use identifiers consisting of an underscore followed by a digit or lower case letter at function, block, or prototype scope.
3. You may use names matching standard macro names if you don't #include any header files which #define them.
4. You may use names of standard library routines as static or local variables (strictly speaking, as identifiers with internal or no linkage).
5. You may use standard typedef and tag names if you don't #include any header files which declare them.
However, before making use of any of these exceptions, recognize that some of them are pretty risky (especially exceptions 3 and 5, since you could accidentally #include the relevant header file at a later time, perhaps through a chain of nested #include files), and others (especially the ones labeled 1,2) represent sort of a ``no man's land'' between the user namespaces and the namespaces reserved to the implementation.
One reason for providing these exceptions is to allow the implementors of various add-in libraries a way to declare their own internal or ``hidden'' identifiers. If you make use of any of the exceptions, you won't clash with any identifiers defined by the Standard, but you might clash with something defined by a third-party library you're using. (If, on the other hand, you're the one who's implementing an add-on library, you're welcome to make use of them, if necessary, and if you're careful.)
(It is generally safe to make use of exception 4 to give function parameters or local variables names matching standard library routines or ``future directions'' patterns. For example, ``string'' is a common--and legal--name for a parameter or local variable.)

----------------------------------------------------------------------------------

 Question 1.30

Q: What am I allowed to assume about the initial values of variables and arrays which are not explicitly initialized?
If global variables start out as ``zero'', is that good enough for null pointers and floating-point zeroes?
A: Uninitialized variables with static duration (that is, those declared outside of functions, and those declared with the storage class static), are guaranteed to start out as zero, just as if the programmer had typed ``= 0'' or ``= {0}''. Therefore, such variables are implicitly initialized to the null pointer (of the correct type; see also section 5) if they are pointers, and to 0.0 if they are floating-point.
Variables with automatic duration (i.e. local variables without the static storage class) start out containing garbage, unless they are explicitly initialized. (Nothing useful can be predicted about the garbage.) If they do have initializers, they are initialized each time the function is called (or, for variables local to inner blocks, each time the block is entered at the top).
These rules do apply to arrays and structures (termed aggregates); arrays and structures are considered ``variables'' as far as initialization is concerned. When an automatic array or structure has a partial initializer, the remainder is initialized to 0, just as for statics. See also question 1.31.
Finally, dynamically-allocated memory obtained with malloc and realloc is likely to contain garbage, and must be initialized by the calling program, as appropriate. Memory obtained with calloc is all-bits-0, but this is not necessarily useful for pointer or floating-point values (see question 7.31, and section 5).

----------------------------------------------------------------------------------

 Question 1.31

Q: This code, straight out of a book, isn't compiling:
int f()
{
    char a[] = "Hello, world!";
}
A: Perhaps you have an old, pre-ANSI compiler, which doesn't allow initialization of ``automatic aggregates'' (i.e. non-static local arrays, structures, or unions). You have four possible workarounds:
If the array won't be written to or if you won't need a fresh copy during any subsequent calls, you can declare it static (or perhaps make it global).
If the array won't be written to, you could replace it with a pointer:
    f()
    {
        char *a = "Hello, world!";
    }
You can always initialize local char * variables to point to string literals (but see question 1.32).
If neither of the above conditions hold, you'll have to initialize the array by hand with strcpy when the function is called:
    f()
    {
        char a[14];
        strcpy(a, "Hello, world!");
    }
Get an ANSI-compatible compiler.
See also question 11.29a.

----------------------------------------------------------------------------------

 Question 1.31b

Q: What's wrong with this initialization?
char *p = malloc(10);
My compiler is complaining about an ``invalid initializer'', or something.
A: Is the declaration of a static or non-local variable? Function calls are allowed in initializers only for automatic variables (that is, for local, non-static variables).

----------------------------------------------------------------------------------

 Question 1.32

Q: What is the difference between these initializations?
char a[] = "string literal";
char *p  = "string literal";
My program crashes if I try to assign a new value to p[i].
A: A string literal (the formal term for a double-quoted string in C source) can be used in two slightly different ways:
As the initializer for an array of char, as in the declaration of char a[] , it specifies the initial values of the characters in that array (and, if necessary, its size).
Anywhere else, it turns into an unnamed, static array of characters, and this unnamed array may be stored in read-only memory, and which therefore cannot necessarily be modified. In an expression context, the array is converted at once to a pointer, as usual (see section 6), so the second declaration initializes p to point to the unnamed array's first element.
Some compilers have a switch controlling whether string literals are writable or not (for compiling old code), and some may have options to cause string literals to be formally treated as arrays of const char (for better error catching).

----------------------------------------------------------------------------------

Question 1.33

Q: Is char a[3] = "abc"; legal?
A: Yes. See question 11.22.

----------------------------------------------------------------------------------

 Question 1.34

Q: I finally figured out the syntax for declaring pointers to functions, but now how do I initialize one?
A: Use something like
extern int func();
int (*fp)() = func;
When the name of a function appears in an expression, it ``decays'' into a pointer (that is, it has its address implicitly taken), much as an array name does.
A prior, explicit declaration for the function (perhaps in a header file) is normally needed, as shown. The implicit external function declaration that can occur when a function is called does not help when a function name's only use is for its value.
See also questions 1.25 and 4.12.

----------------------------------------------------------------------------------

Question 1.35

Q: Can I initialize unions?
A: See question 2.20.

----------------------------------------------------------------------------------