faqcatd3c2.html

this is a mirrored site c-faq. thought might need offline

identifiers beginning with an underscore
followed by an upper-case letter or another underscore
are always reserved
(all scopes, all namespaces).
<li>2.
All
identifiers beginning with an underscore
are reserved for ordinary identifiers
(functions, variables, typedefs, enumeration constants)
with file scope.

<li>3.
A
macro name defined in a standard header
is reserved for any use
if


any
header which <TT>#define</TT>s it is <TT>#include</TT>d.
<li>4.
All
standard library identifiers
with external linkage
(e.g. function names)
are always reserved
as identifiers with external linkage.
<li>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 <TT>#include</TT>d.
(The Standard really says
``each identifier with file scope,''
but the only standard identifiers not covered by rule 4
are typedef and tag names.)
</UL><p>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.
</p><p>Here is a list of the patterns which are reserved for 
``future directions''
associared with each standard header:
<blockquote>[TABLE GOES HERE]
</blockquote>(The notation <TT>[A-Z]</TT> means ``any uppercase letter'';
similarly, <TT>[a-z]</TT> and <TT>[0-9]</TT> indicate lower-case 
letters and digits.
The notation <TT>*</TT> means ``anything.''
For example,
the pattern for <TT>&lt;stdlib.h&gt;</TT> says that
all external identifiers beginning with the letters <TT>str</TT>
followed by a lower-case letter
are reserved.)
</p><p>What do the
above
rules really mean?
If you want to be on the safe side:
</p><UL><li>1,2.
Don't
give anything a name
with a leading underscore.
<li>3.
Don't
give anything a name
which is already a
standard macro
(including the ``future directions'' patterns).
<li>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 <a href="faqcat7d4b.html?sec=ansi#extidsignif">11.27</a>.)
<li>5.
Don't redefine standard typedef

or tag names.
</UL><p>In fact,
the preceding
subparagraphs

are overly conservative.
If you wish,
you may

remember the following exceptions:
</p><UL><li>1,2.
You may use identifiers consisting of
an underscore
followed by a digit or lower case letter
for labels and structure/union members.
<li>1,2.
You may use identifiers consisting of
an underscore
followed by a digit or lower case letter
at function, block, or prototype scope.
<li>3.
You may use names matching standard macro names
if you don't <TT>#include</TT> any header files which <TT>#define</TT> them.
<li>4.
You may use names of standard library routines as static or 
local variables
(strictly speaking, as identifiers with internal or no linkage).
<li>5.
You may use standard typedef and tag names
if you don't <TT>#include</TT> any header files which declare them.
</UL><p>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 <TT>#include</TT> the relevant header file
at a later time,
perhaps through a chain of nested <TT>#include</TT> 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.
</p><p>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.)
</p><p>
(It <em>is</em>

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,
``<TT>string</TT>''
is a
common--and legal--name
for a
parameter or local variable.)
</p><p>Additional links:
<a href="http://www.concentric.net/~Brownsta/c-predef.htm">Stan Brown's comprehensive list of reserved identifiers</a>
</p>










<p>References:

ISO Sec. 6.1.2.1, Sec. 6.1.2.2, Sec. 6.1.2.3, Sec. 7.1.3, Sec. 7.13
<br>
Rationale Sec. 4.1.2.1
<br>
H&amp;S Sec. 2.5 pp. 21-3, Sec. 4.2.1 p. 67, Sec. 4.2.4 pp. 69-70, Sec. 4.2.7 p. 78, Sec. 10.1 p. 284
<hr><hr><hr>
<a name="initval">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../decl/initval.html"><!-- qtag -->Question 1.30</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What
am I allowed to
assume about the initial values of variables
and arrays
which are not explicitly initialized?
<br>If global variables start out as ``zero'',
is that good enough
for null pointers and floating-point zeroes?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Uninitialized
variables
with
<a href="../../sx1/index.html#static"><dfn>static</dfn></a>
duration

(that is,
those declared outside of functions,
and those declared with the storage class <TT>static</TT>),
are guaranteed
to
start out as
zero,
just
as if the programmer had typed ``<TT>=&nbsp;0</TT>''
or ``<TT>=&nbsp;{0}</TT>''.
Therefore,
such variables are
implicitly
initialized
to the null pointer
(of the correct type;
see also section
<a href="faqcat1f1a.html?sec=null#index">5</a>)
if they are pointers,
and
to 0.0 if they are floating-point.
<a href="../../decl/zerofill.html" rel=subdocument>[footnote]</a>
</p><p>Variables with
<a href="../../sx1/index.html#automatic"><dfn>automatic</dfn></a>
duration
(i.e. local variables without the <TT>static</TT> 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<a href="../../decl/jumpinto.html" rel=subdocument>[footnote]</a>
).
</p><p>These rules do apply to arrays and structures
(termed <a href="../../sx1/index.html#aggregates"><dfn>aggregates</dfn></a>);
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.
<a href="../../decl/krerr.html" rel=subdocument>[footnote]</a>
See also question <a href="faqcatd3c2.html?sec=decl#autoaggrinit">1.31</a>.
</p><p>Finally,
dynamically-allocated memory
obtained with <TT>malloc</TT> and <TT>realloc</TT>
is likely to contain garbage,
and must be initialized by the calling program,
as appropriate.
Memory obtained with <TT>calloc</TT>
is
all-bits-0,
but this is not necessarily useful
for pointer or floating-point values
(see question
<a href="faqcatbafd.html?sec=malloc#calloc">7.31</a>,
and section
<a href="faqcat1f1a.html?sec=null#index">5</a>).
</p>












<p>References:

K&amp;R1 Sec. 4.9 pp. 82-4
<br>
K&amp;R2 Sec. 4.9 pp. 85-86
<br>
ISO Sec. 6.5.7, Sec. 7.10.3.1, Sec. 7.10.5.3
<br>
H&amp;S Sec. 4.2.8 pp. 72-3, Sec. 4.6 pp. 92-3, Sec. 4.6.2 pp. 94-5, Sec. 4.6.3 p. 96, Sec. 16.1 p. 386
<hr><hr><hr>
<a name="autoaggrinit">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../decl/autoaggrinit.html"><!-- qtag -->Question 1.31</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
This code, straight out of a book, isn't compiling:
<pre>
int f()
{
	char a[] = "Hello, world!";
}
</pre>
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Perhaps you have
an old,
pre-ANSI compiler,
which doesn't allow initialization of ``automatic aggregates''
(i.e. non-<TT>static</TT> local arrays, structures,
or
unions).
You have four possible workarounds:
<OL><li>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 <TT>static</TT>
(or perhaps make it global).
<li>If
the array won't be written to,
you could
replace it with a pointer:
<pre>
	f()
	{
		char *a = "Hello, world!";
	}
</pre>
You
can always initialize local <TT>char&nbsp;*</TT> variables



to point to
string literals
(but
see question
<a href="faqcatd3c2.html?sec=decl#strlitinit">1.32</a>).
<li>If neither of
the above
conditions hold,
you'll have to



initialize
the array
by hand
with <TT>strcpy</TT>
when
the function
is called:
<pre>
	f()
	{
		char a[14];
		strcpy(a, "Hello, world!");
	}
</pre>
<li>Get an ANSI-compatible compiler.
</OL></p><p>See also question
<a href="faqcat7d4b.html?sec=ansi#preansi">11.29a</a>.
<hr><hr><hr>
<a name="fcninit">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../decl/fcninit.html"><!-- qtag -->Question 1.31b</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What's wrong with
this initialization?
<pre>
char *p = malloc(10);</pre>

My compiler is complaining about
an ``invalid initializer'',
or something.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
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-<TT>static</TT> variables).
<hr><hr><hr>
<a name="strlitinit">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../decl/strlitinit.html"><!-- qtag -->Question 1.32</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What is the difference between
these initializations?
<pre>
char a[] = "string literal";
char *p  = "string literal";
</pre>
My program
crashes if
I try to
assign a new value to <TT>p[i]</TT>.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
A string literal
(the formal
term
for a double-quoted string in C source)
can
be used in
two slightly different
ways:
<OL><li>
As
the initializer for an array of <TT>char</TT>,
as in the
declaration of <TT>char&nbsp;a[]</TT>
,
it specifies the initial values of the characters in that array

(and, if necessary, its size).
<li>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 <a href="faqcatca65.html?sec=aryptr#index">6</a>),
so
the second declaration initializes
<TT>p</TT>
to point to
the
unnamed
array's
first element.
</OL></p><p>

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 <TT>const</TT> <TT>char</TT>
(for better error catching).
</p><p>See also questions
<a href="faqcatd3c2.html?sec=decl#autoaggrinit">1.31</a>,
<a href="faqcatca65.html?sec=aryptr#aryptr1">6.1</a>,
<a href="faqcatca65.html?sec=aryptr#aryptr2">6.2</a>,
<a href="faqcatca65.html?sec=aryptr#practdiff">6.8</a>,
and
<a href="faqcat7d4b.html?sec=ansi#strlitnotconst">11.8b</a>.
</p>




<p>References:

K&amp;R2 Sec. 5.5 p. 104
<br>
ISO Sec. 6.1.4, Sec. 6.5.7
<br>
Rationale Sec. 3.1.4
<br>
H&amp;S Sec. 2.7.4 pp. 31-2
<hr><hr><hr>
<a name="nonstring">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../decl/nonstring.html"><!-- qtag -->Question 1.33</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Is <TT>char&nbsp;a[3]&nbsp;=&nbsp;"abc";</TT> legal?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Yes.
See question <a href="faqcat7d4b.html?sec=ansi#nonstrings">11.22</a>.
<hr><hr><hr>
<a name="ptrfuncinit">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../decl/ptrfuncinit.html"><!-- qtag -->Question 1.34</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I finally figured out the syntax for declaring pointers to
functions, but now how do I initialize one?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Use something like
<pre>
extern int func();
int (*fp)() = func;</pre>

</p><p>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.
</p><p>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.
</p><p>See also questions
<a href="faqcatd3c2.html?sec=decl#implfdecl">1.25</a>
and
<a href="faqcatabdc.html?sec=ptrs#funccall">4.12</a>.

<hr><hr><hr>
<a name="initunion">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../decl/initunion.html"><!-- qtag -->Question 1.35</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Can I initialize unions?
</p>
<p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
See question <a href="faqcat6b6b.html?sec=struct#initunion">2.20</a>.
<hr><hr><hr>
<hr>
<p>
Read sequentially:
<a href="faqcat321f.html?sec=" rev=precedes>prev</a>
<a href="faqcat6b6b.html?sec=struct" rel=precedes>next</a>
<a href="faqcat.html" rev=subdocument>up</a>
</p>
<hr>
<p>
<br><!-- lastfooter -->
<a href="../../about.html">about this FAQ list</a>
&nbsp;
<a href="../../eskimo.html">about eskimo</a>
&nbsp;
<a href="../../search.html">search</a>
&nbsp;
<a href="../../feedback.html">feedback</a>
&nbsp;
<a href="../../decl/copyright.html">copyright</a>
<p>
Hosted by
<a href="http://www.eskimo.com/"><img src="../../../www.eskimo.com/img/link/eskitiny.gif" alt="Eskimo North"></a>
</body>

<!-- Mirrored from c-faq.com/~scs/cgi-bin/faqcat.cgi?sec=decl by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 07:57:33 GMT -->
</html>