comp.lang.c Frequently Asked Questions
comp.lang.c Frequently Asked Questions
This collection of hypertext pages is Copyright 1995 by Steve Summit. Content from the book ``C 
Programming FAQs: Frequently Asked Questions'' (Addison-Wesley, 1995, ISBN 0-201-84519-9) is 
made available here by permission of the author and the publisher as a service to the community. It is 
intended to complement the use of the published text and is protected by international copyright laws. 
The content is made available here and may be accessed freely for personal use but may not be published 
or retransmitted without written permission. 
This page is the top of an HTML version of the Usenet comp.lang.c Frequently Asked Questions (FAQ) 
list. An FAQ list is a collection of questions commonly asked on Usenet, together with presumably 
definitive answers, provided in an attempt to keep repeated questions on the newsgroup down to a low 
background drone so that discussion can move on to more interesting matters. Since they distill 
knowledge gleaned from many sources and answer questions which are demonstrably Frequent, FAQ 
lists serve as useful references outside of their originating Usenet newsgroups. This list is, I dare to 
claim, no exception, and the HTML version you're looking at now, as well as other versions referenced 
just below, are intended to be useful to C programmers everywhere. 
Several other versions of this FAQ list are available, including a book-length version published by 
Addison-Wesley. (The book, though longer, also has a few more errors; I've prepared an errata list.) See 
also question 20.40. 
Like so many web pages, this is very much a ``work in progress.'' I would, of course, like it if it were 
perfect, but it's been two years or so since I first started talking about putting this thing on the web, and if 
I were to wait until all the glitches were worked out, you might never see it. Each page includes a ``mail 
feedback'' button, so you can help me debug it. (At first, you don't have to worry about reporting minor 
formatting hiccups; many of these result from lingering imperfections in the programs that generate these 
pages, or from the fact that I have not exhaustively researched how various browsers implement the 
HTML tags I'm using, or from the fact that I haven't gone the last yard in trying to rig up HTML that 
looks good in spite of the fact that HTML doesn't have everything you need to make things look good.) 
These pages are synchronized with the posted Usenet version and the Addison-Wesley book version. 
Since not all questions appear in all versions, the question numbers are not always contiguous. 
[Note to web authors, catalogers, and bookmarkers: the URL  is the right way to link to these pages. All other URL's implementing this collection are 
subject to change.] 
You can browse these pages in at least three ways. The table of contents below is of the list's major 
sections; these links lead to sub-lists of the questions for those sections. The ``all questions'' link leads to 
a list of all the questions; each question is (obviously) linked to its answer. Finally, the ``read 
http://www.eskimo.com/~scs/C-faq/top.html (1 of 3) [2003-07-28 ÿÿ€ÿˆÿ„ 9:05:16]
comp.lang.c Frequently Asked Questions
sequentially'' link leads to the first question; you can then follow the ``next'' link at the bottom of each 
question's page to read through all of the questions and answers sequentially. 
Steve Summit 
scs@eskimo.com 
1. Declarations and Initializations
2. Structures, Unions, and Enumerations
3. Expressions
4. Pointers
5. Null Pointers
6. Arrays and Pointers
7. Memory Allocation
8. Characters and Strings
9. Boolean Expressions and Variables
10. C Preprocessor
11. ANSI/ISO Standard C
12. Stdio
13. Library Functions
14. Floating Point
15. Variable-Length Argument Lists
16. Strange Problems
http://www.eskimo.com/~scs/C-faq/top.html (2 of 3) [2003-07-28 ÿÿ€ÿˆÿ„ 9:05:16]
comp.lang.c Frequently Asked Questions
17. Style
18. Tools and Resources
19. System Dependencies
20. Miscellaneous
Bibliography
Acknowledgements
All Questions 
Read Sequentially 
http://www.eskimo.com/~scs/C-faq/top.html (3 of 3) [2003-07-28 ÿÿ€ÿˆÿ„ 9:05:16]
Declarations and Initializations
1. Declarations and Initializations
1.1 How do you decide which integer type to use? 
1.4 What should the 64-bit type on new, 64-bit machines be? 
1.7 What's the best way to declare and define global variables? 
1.11 What does extern mean in a function declaration? 
1.12 What's the auto keyword good for? 
1.14 I can't seem to define a linked list node which contains a pointer to itself. 
1.21 How do I declare an array of N pointers to functions returning pointers to functions returning 
pointers to characters? 
1.22 How can I declare a function that returns a pointer to a function of its own type? 
1.25 My compiler is complaining about an invalid redeclaration of a function, but I only define it once 
and call it once. 
1.30 What can I safely assume about the initial values of variables which are not explicitly initialized? 
1.31 Why can't I initialize a local array with a string? 
1.32 What is the difference between char a[] = "string"; and char *p = "string"; ? 
1.34 How do I initialize a pointer to a function? 
top 
http://www.eskimo.com/~scs/C-faq/s1.html [2003-07-28 ÿÿ€ÿˆÿ„ 9:05:35]
Question 1.1
Question 1.1
How do you decide which integer type to use? 
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.) 
Although character types (especially unsigned char) can be used as ``tiny'' integers, doing so is 
sometimes more trouble than it's worth, due to unpredictable sign extension and increased code size. 
(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. None of the above 
rules apply if the address of a variable is taken and must have a particular type. 
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. 
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 
ANSI Sec. 2.2.4.2.1, Sec. 3.1.2.5 
ISO Sec. 5.2.4.2.1, Sec. 6.1.2.5 
H&S Secs. 5.1,5.2 pp. 110-114 
Read sequentially: next up top 
This page by Steve Summit // Copyright 1995 // mail feedback 
http://www.eskimo.com/~scs/C-faq/q1.1.html [2003-07-28 ÿÿ€ÿˆÿ„ 9:05:55]
Question 1.4
Question 1.4
What should the 64-bit type on new, 64-bit machines be? 
Some vendors of C products for 64-bit machines support 64-bit long ints. Others fear that too much 
existing code is written to assume that ints and longs are the same size, or that one or the other of 
them is exactly 32 bits, and introduce a new, nonstandard, 64-bit long long (or __longlong) type 
instead. 
Programmers interested in writing portable code should therefore insulate their 64-bit type needs behind 
appropriate typedefs. Vendors who feel compelled to introduce a new, longer integral type should 
advertise it as being ``at least 64 bits'' (which is truly new, a type traditional C does not have), and not 
``exactly 64 bits.'' 
References: ANSI Sec. F.5.6 
ISO Sec. G.5.6 
Read sequentially: prev next up top 
This page by Steve Summit // Copyright 1995 // mail feedback 
http://www.eskimo.com/~scs/C-faq/q1.4.html [2003-07-28 ÿÿ€ÿˆÿ„ 9:06:13]
Question 1.7
Question 1.7
What's the best way to declare and define global variables? 
First, though there can be many declarations (and in many translation units) of a single ``global'' (strictly 
speaking, ``external'') variable or function, there must be exactly one definition. (The definition is the 
declaration that actually allocates space, and provides an initialization value, if any.) The best 
arrangement is to place each definition in some relevant .c file, with an external declaration in a header 
(``.h'') file, which is #included wherever the declaration is needed. The .c file containing the definition 
should also #include the same header file, so that 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 
odd systems may require 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. 
It's especially important to put global declarations in header files if you want the compiler to catch 
inconsistent declarations for you. In particular, never place a prototype for an external function in a .c 
file: it wouldn't generally be checked for consistency with the definition, and an incompatible prototype 
is worse than useless. 
See also questions 10.6 and 18.8. 
References: K&R1 Sec. 4.5 pp. 76-7 
K&R2 Sec. 4.4 pp. 80-1 
ANSI Sec. 3.1.2.2, Sec. 3.7, Sec. 3.7.2, Sec. F.5.11 
ISO Sec. 6.1.2.2, Sec. 6.7, Sec. 6.7.2, Sec. G.5.11 
Rationale Sec. 3.1.2.2 
H&S Sec. 4.8 pp. 101-104, Sec. 9.2.3 p. 267 
CT&P Sec. 4.2 pp. 54-56 
http://www.eskimo.com/~scs/C-faq/q1.7.html (1 of 2) [2003-07-28 ÿÿ€ÿˆÿ„ 9:06:18]
Question 1.7
Read sequentially: prev next up top 
This page by Steve Summit // Copyright 1995 // mail feedback 
http://www.eskimo.com/~scs/C-faq/q1.7.html (2 of 2) [2003-07-28 ÿÿ€ÿˆÿ„ 9:06:18]