faqcat7d4b.html

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

only during preprocessor macro expansion.
You cannot use them in 

normal

source code,
but
only in macro definitions.
</p>




<p>References:

ISO Sec. 6.8.3.2, Sec. 6.8.3.5
<hr><hr><hr>
<a name="macstrexp">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/macstrexp.html"><!-- qtag -->Question 11.18</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What does the message
``warning: macro replacement within a string literal''
mean?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Some
pre-ANSI compilers/preprocessors

interpreted macro definitions like
<pre>
	#define TRACE(var, fmt) printf("TRACE: var = fmt\n", var)
</pre>
such that invocations like
<pre>
	TRACE(i, %d);
</pre>
were expanded as
<pre>
	printf("TRACE: i = %d\n", i);
</pre>
In other words, macro parameters were
expanded
even inside



string literals and character constants.
(This interpretation may even have been an accident of early implementations,
but it can prove useful for macros like this.)
</p><p>Macro expansion is <em>not</em> defined in this way
by K&amp;R or by Standard C.
(It can be dangerous and confusing:
see question <a href="faqcat204f.html?sec=cpp#macstrexp2">10.22</a>.)
When you do want
to turn macro arguments into strings,
you can use the new <TT>#</TT> preprocessing operator,
along with string literal concatenation
(another new ANSI feature):
<pre>
	#define TRACE(var, fmt) \
		printf("TRACE: " #var " = " #fmt "\n", var)
</pre>
See also question <a href="faqcat7d4b.html?sec=ansi#stringize">11.17</a>.
</p>
<p>References:

H&amp;S Sec. 3.3.8 p. 51
<hr><hr><hr>
<a name="ifdefsyntax">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/ifdefsyntax.html"><!-- qtag -->Question 11.19</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I'm getting strange syntax errors inside
lines
I've
<TT>#ifdef</TT>fed out.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Under ANSI C,
the text inside a ``turned off''

<TT>#if</TT>, <TT>#ifdef</TT>, or <TT>#ifndef</TT>
must still consist of ``valid preprocessing
tokens.''
This means that



the characters <TT>"</TT> and <TT>'</TT> must each be paired just as in
real C code,
and the pairs mustn't cross line boundaries.
(Note particularly that an apostrophe
within a contracted word
looks like the beginning of a character constant.)
Therefore, natural-language comments
and pseudocode
should always be written
between the ``official'' comment delimiters <TT>/*</TT> and <TT>*/</TT>.
(But see question
<a href="faqcat38c2.html?sec=misc#nestcomment">20.20</a>,
and
also
<a href="faqcat204f.html?sec=cpp#notgeneral">10.25</a>.)
</p>


<p>References:

ISO Sec. 5.1.1.2, Sec. 6.1
<br>
H&amp;S Sec. 3.2 p. 40
<hr><hr><hr>
<a name="pragma">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/pragma.html"><!-- qtag -->Question 11.20</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What are <TT>#pragma</TT>s 
and what are they good for?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
The <TT>#pragma</TT> directive

provides a single, well-defined
``escape hatch'' which can be used for
all sorts of
(nonportable)
implementation-specific controls and extensions:
source listing control,
structure packing,
warning suppression
(like <TT>lint</TT>'s old <TT>/*&nbsp;NOTREACHED&nbsp;*/</TT> comments),
etc.
</p>

<p>References:

ISO Sec. 6.8.6
<br>
H&amp;S Sec. 3.7 p. 61
<hr><hr><hr>
<a name="pragmaonce">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/pragmaonce.html"><!-- qtag -->Question 11.21</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What does ``<TT>#pragma&nbsp;once</TT>'' mean?
I found it in some header files.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
It is an extension implemented by some preprocessors to help make
header files idempotent;
that is,
to make sure that
their contents are processed exactly once
even if they are <TT>#include</TT>d multiple times.
It
is
equivalent to the
<TT>#ifndef</TT> trick mentioned in question
<a href="faqcat204f.html?sec=cpp#nestincl">10.7</a>,
though less portable.
Some people claim that <TT>#pragma&nbsp;once</TT> can be implemented
``more efficiently''
(of course only compilation efficiency is a factor here),
but in fact a preprocessor that is serious
about compilation efficiency can arrange for the

portable
<TT>#ifndef</TT> trick to be handled just
as efficiently.

<hr><hr><hr>
<a name="nonstrings">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/nonstrings.html"><!-- qtag -->Question 11.22</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?
What does it mean?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
It is legal


in ANSI C
(and perhaps in a few pre-ANSI systems),
though useful only in rare circumstances.
It declares an array of size three,
initialized with the three characters <TT>'a'</TT>, <TT>'b'</TT>, and <TT>'c'</TT>,
<em>without</em> the usual terminating <TT>'\0'</TT> character.


The array is therefore not a true C string
and cannot be used
with <TT>strcpy</TT>,
<TT>printf</TT>'s <TT>%s</TT> format,
etc.
</p><p>


Most of the time, you should let the compiler count the 
initializers when initializing arrays
(in the case of the initializer <TT>"abc"</TT>, of course,
the computed size will be 4).
</p>

<p>References:

ISO Sec. 6.5.7
<br>
H&amp;S Sec. 4.6.4 p. 98
<hr><hr><hr>
<a name="aryvsadr">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/aryvsadr.html"><!-- qtag -->Question 11.23</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Since array references decay into pointers,
if <TT>arr</TT> is an array,
what's
the difference between
<TT>arr</TT> and <TT>&amp;arr</TT>?
</p>
<p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
See question <a href="faqcatca65.html?sec=aryptr#aryvsadr">6.12</a>.
<hr><hr><hr>
<a name="voidparith">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/voidparith.html"><!-- qtag -->Question 11.24</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Why can't I perform arithmetic on a <TT>void&nbsp;*</TT> pointer?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
The compiler doesn't know the size of the pointed-to
objects.
(Remember that pointer arithmetic
is always in terms of
the pointed-to size;
see also question <a href="faqcatabdc.html?sec=ptrs#explscale">4.4</a>.)
Therefore,
arithmetic on <TT>void&nbsp;*</TT>'s is disallowed
(though some compilers

allow it as an extension).
Before performing arithmetic,
convert the pointer either to <TT>char&nbsp;*</TT>
or to the

pointer
type you're trying to manipulate
(but see also
questions <a href="faqcatabdc.html?sec=ptrs#castincr">4.5</a> and <a href="faqcat5e04.html?sec=strangeprob#ptralign">16.7</a>).

</p>


<p>References:

ISO Sec. 6.1.2.5, Sec. 6.3.6
<br>
H&amp;S Sec. 7.6.2 p. 204
<hr><hr><hr>
<a name="memmove">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/memmove.html"><!-- qtag -->Question 11.25</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What's the difference between
<TT>memcpy</TT> and
<TT>memmove</TT>?

</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
<TT>memmove</TT> offers guaranteed behavior
if the
memory
regions

pointed to by the
source and destination arguments

overlap.
<TT>memcpy</TT> makes no such guarantee,
and may therefore be more efficiently implementable.
When in doubt, it's safer to use <TT>memmove</TT>.
</p><p>It seems
simple enough to implement <TT>memmove</TT>;
the overlap guarantee
apparently requires
only an additional test:
<pre>
void *memmove(void *dest, void const *src, size_t n)
{
	register char *dp = dest;
	register char const *sp = src;
	if(dp &lt; sp) {
		while(n-- &gt; 0)
			*dp++ = *sp++;
	} else {
		dp += n;
		sp += n;
		while(n-- &gt; 0)
			*--dp = *--sp;
	}

	return dest;
}
</pre>
The problem
with this code
is in that additional test:
the comparison
<TT>(dp&nbsp;&lt;&nbsp;sp)</TT>
is not quite portable
(it compares two pointers
which do not necessarily point within the same object)
and may not be as cheap as it looks.
On some machines
(particularly segmented architectures),
it may be tricky and significantly less efficient
<a href="../../ansi/norml.html" rel=subdocument>[footnote]</a>
to implement.
</p>





<p>References:

K&amp;R2 Sec. B3 p. 250
<br>
ISO Sec. 7.11.2.1, Sec. 7.11.2.2
<br>
Rationale Sec. 4.11.2
<br>
H&amp;S Sec. 14.3 pp. 341-2
<br>
PCS Sec. 11 pp. 165-6
<hr><hr><hr>
<a name="malloc0">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/malloc0.html"><!-- qtag -->Question 11.26</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What should <TT>malloc(0)</TT> do?
Return a null pointer or a pointer to 0 bytes?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
The ANSI/ISO Standard says that it may do either;
the
behavior is implementation-defined
(see question <a href="faqcat7d4b.html?sec=ansi#undef">11.33</a>).
Portable code must either
take care not to call <TT>malloc(0)</TT>,
or be prepared for
the possibility of a null return.
</p>

<p>References:

ISO Sec. 7.10.3
<br>
PCS Sec. 16.1 p. 386
<hr><hr><hr>
<a name="extidsignif">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/extidsignif.html"><!-- qtag -->Question 11.27</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Why does the ANSI Standard
place limits on
the length
and case-significance
of

external identifiers?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
The problem is
linkers
which are
under control of
neither
the ANSI/ISO Standard nor
the C compiler developers on the systems which have them.

The limitation is only that identifiers be
<em>significant</em>
in some initial sequence of characters,
not that they be restricted to
that many characters
in total
length.
(The limitation was to six characters
in the original ANSI Standard,
but has been relaxed to
31

in C99.)
</p>




<p>References:

ISO Sec. 6.1.2, Sec. 6.9.1
<br>
Rationale Sec. 3.1.2
<br>
C9X Sec. 6.1.2
<br>
H&amp;S Sec. 2.5 pp. 22-3
<hr><hr><hr>
<a name="noalias">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/noalias.html"><!-- qtag -->Question 11.28</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What was <TT>noalias</TT> and what ever happened to it?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
<TT>noalias</TT> was another type qualifier,
in the same syntactic class as <TT>const</TT> and <TT>volatile</TT>,
which was intended to assert that
an
object
was not
pointed to (``aliased'') by other pointers.
The primary application,
which is an important one,
would have been for the formal parameters of functions
designed to perform computations on large arrays.
A compiler cannot usually take advantage of vectorization
or other parallelization
hardware
(on supercomputers which have it)
unless it can ensure
that the source and destination arrays do not overlap.
</p><p>The <TT>noalias</TT> keyword was not backed up by any ``prior art,''
and it was introduced late in the review and approval process.
It was
surprisingly
difficult to define precisely and explain coherently,
and sparked widespread, acrimonious debate,
including a scathing pan by Dennis Ritchie.
It had far-ranging implications,
particularly for several standard library interfaces,
for which easy fixes were not readily apparent.
</p><p>Because of the criticism and the difficulty of defining
<TT>noalias</TT> well,
the Committee

declined to adopt it,
in spite of its superficial

attractions.
(When writing a standard,
features cannot be introduced halfway;
their full integration,
and all implications,
must be understood.)
The need for an explicit mechanism
to support parallel implementation of
non-overlapping operations remains

unfilled
(although
some work is being done
on
the problem).
</p>
<p>References:

ISO Sec. 6.9.6
<hr><hr><hr>
<a name="preansi">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/preansi.html"><!-- qtag -->Question 11.29a</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
My compiler is rejecting the simplest possible test programs,
with all kinds of syntax errors.
It's complaining about the
first line of
<pre>
	main(int argc, char **argv)
	{
		return 0;
	}
</pre>
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Perhaps it is a pre-ANSI compiler,
unable to accept function prototypes and the like.
</p><p>See also questions
<a href="faqcatd3c2.html?sec=decl#autoaggrinit">1.31</a>,
<a href="faqcat204f.html?sec=cpp#headerglom">10.9</a>,
<a href="faqcat7d4b.html?sec=ansi#preansilib">11.30</a>,
and
<a href="faqcat5e04.html?sec=strangeprob#unclosed">16.1b</a>.
</p><p>If you don't have access to an ANSI compiler,
and you need to convert some newer code
(such as that in this list)
so that you can compile it,
perform these steps:

</p><OL><li>Remove
the argument type information from
function prototype declarations,
and convert prototype-style function definitions to old style.
The new-style declarations
<pre>
	extern int f1(void);
	extern int f2(int);
	int main(int argc, char **argv) { ... }
	int f3(void) { ... }
</pre>
would be

rewritten as