faqcat7d4b.html

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

comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/constptrconst.html"><!-- qtag -->Question 11.9</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What's the difference between
<TT>const&nbsp;char&nbsp;*p</TT>,
<TT>char&nbsp;const&nbsp;*p</TT>,
and <TT>char&nbsp;*&nbsp;const&nbsp;p</TT>?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
The first two

are interchangeable;
they
declare
a pointer to a constant character
(you can't change
any pointed-to characters).
<TT>char&nbsp;*&nbsp;const&nbsp;p</TT>
declares a constant pointer to a
(variable)
character
(i.e. you can't change the pointer).
</p><p>Read these
declarations
``inside out'' to understand them;
see
question
<a href="faqcatd3c2.html?sec=decl#cdecl1">1.21</a>.
</p>



<p>References:

ISO Sec. 6.5.4.1
<br>
Rationale Sec. 3.5.4.1
<br>
H&amp;S Sec. 4.4.4 p. 81
<hr><hr><hr>
<a name="constmismatch">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/constmismatch.html"><!-- qtag -->Question 11.10</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>



Why can't I pass a <TT>char&nbsp;**</TT> to a function which expects a
<TT>const&nbsp;char&nbsp;**</TT>?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
You can use a pointer-to-T (for any type T) where a
pointer-to-const-T is expected.
However,
the
rule
(an explicit exception)
which permits slight mismatches
in qualified pointer
types
is not applied recursively,
but only at the top level.
(<TT>const&nbsp;char&nbsp;**</TT> is
pointer-to-pointer-to-const-char,
and the exception

therefore does not apply.)
</p><p>The reason that you cannot assign a
<TT>char&nbsp;**</TT> value to a <TT>const&nbsp;char&nbsp;**</TT>
pointer is somewhat obscure.
Given that the <TT>const</TT> qualifier exists at all,
the compiler would like to help you keep your promises not to 
modify <TT>const</TT> values.
That's why you can assign
a <TT>char&nbsp;*</TT> to a <TT>const&nbsp;char&nbsp;*</TT>,
but not the other way around:
it's clearly safe to ``add'' <TT>const</TT>-ness to a simple pointer,
but it would be dangerous to take it away.
However, suppose you performed the following

more complicated
series of
assignments:
<pre>
	const char c = 'x';		/* 1 */
	char *p1;			/* 2 */
	const char **p2 = &amp;p1;		/* 3 */
	*p2 = &amp;c;			/* 4 */
	*p1 = 'X';			/* 5 */
</pre>
In line 3,
we assign a <TT>char&nbsp;**</TT> to a <TT>const&nbsp;char&nbsp;**</TT>.
(The compiler should complain.)
In line 4,
we assign a <TT>const&nbsp;char&nbsp;*</TT> to a <TT>const&nbsp;char&nbsp;*</TT>;
this is clearly legal.
In line 5,
we modify what a <TT>char&nbsp;*</TT> points to--this is supposed to be legal.
However, <TT>p1</TT> ends up pointing to <TT>c</TT>,
which is <TT>const</TT>.
This came about in line 4,
because <TT>*p2</TT> was really <TT>p1</TT>.
This was set up in line 3,
which is an assignment of a form that is disallowed,
and this is exactly <em>why</em> line 3 is disallowed.
</p><p>Assigning a <TT>char&nbsp;**</TT> to a <TT>const&nbsp;char&nbsp;**</TT>
(as in line 3, and in the original question)
is not immediately dangerous.
But it sets up a situation in which <TT>p2</TT>'s promise--that
the ultimately-pointed-to value won't be modified--cannot
be kept.
</p><p>(C++
has more complicated rules
for assigning <TT>const</TT>-qualified pointers
which let you make more kinds of assignments
without incurring warnings,
but still protect against inadvertent attempts
to modify <TT>const</TT> values.
C++ would still not allow
assigning a <TT>char&nbsp;**</TT> to a <TT>const&nbsp;char&nbsp;**</TT>,
but it would let you get away with
assigning a <TT>char&nbsp;**</TT>
to a <TT>const&nbsp;char&nbsp;*&nbsp;const&nbsp;*</TT>.)
</p><p>In C,
if
you must
assign or pass
pointers which have qualifier mismatches at
other than the first level of indirection,
you
must use explicit casts
(e.g. <TT>(const&nbsp;char&nbsp;**)</TT> in this case),
although as always,
the need for such a cast may indicate a deeper problem
which the cast doesn't really fix.

</p>



<p>References:

ISO Sec. 6.1.2.6, Sec. 6.3.16.1, Sec. 6.5.3
<br>
H&amp;S Sec. 7.9.1 pp. 221-2
<hr><hr><hr>
<a name="typedefconst">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/typedefconst.html"><!-- qtag -->Question 11.11</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I've got
the declarations
<pre>
	typedef char *charp;
	const charp p;
</pre>
Why is <TT>p</TT> turning out <TT>const</TT>,
instead of the characters pointed to?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
<TT>typedef</TT> substitutions are not purely textual.
(This is one of the advantages of <TT>typedef</TT>s;
see question <a href="faqcatd3c2.html?sec=decl#typedefvsdefine">1.13</a>.)
In the declaration
<pre>
	const charp p;
</pre>
<TT>p</TT> is <TT>const</TT>
for the same reason that <TT>const&nbsp;int&nbsp;i</TT>
declares <TT>i</TT> as <TT>const</TT>.
The <TT>typedef</TT>'ed declaration of <TT>p</TT>
does not ``look inside'' the <TT>typedef</TT> to see that
there is a pointer involved.
</p><p>Additional links:

<a href="faqcat7d4b.html?sec=ansi#typedefconst2">further reading</a>
</p>
<p>References:

H&amp;S Sec. 4.4.4 pp. 81-2
<hr><hr><hr>
<a name="constvsdefine2">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/constvsdefine2.html"><!-- qtag -->Question 11.11b</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What's the difference between
<pre>
	const MAXSIZE = 100;
</pre>
<pre>
and
</pre>
<pre>
	#define MAXSIZE 100
</pre>
</p>
<p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
See question <a href="faqcat204f.html?sec=cpp#constvsdefine">10.5b</a>.
<hr><hr><hr>
<a name="maindecl">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/maindecl.html"><!-- qtag -->Question 11.12a</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What's the correct declaration of <TT>main()</TT>?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
There are
two valid declarations:
<pre>
	int main(void)
	int main(int argc, char **argv)
</pre>
although they
can
be written in a variety of ways.
The second parameter may be declared <TT>char *argv[]</TT>
(see
question <a href="faqcatca65.html?sec=aryptr#aryptrparam">6.4</a>),
you can use any names for the two parameters,
and
you can use
old-style syntax:
<pre>
	int main()

	int main(argc, argv)
	int argc; char **argv;
</pre>
</p><p>See also questions <a href="faqcat7d4b.html?sec=ansi#voidmain">11.12b</a>
to
<a href="faqcat7d4b.html?sec=ansi#voidmainbooks">11.15</a>.
</p>



<p>References:

ISO Sec. 5.1.2.2.1, Sec. G.5.1
<br>
H&amp;S Sec. 20.1 p. 416
<br>
CT&amp;P Sec. 3.10 pp. 50-51
<hr><hr><hr>
<a name="voidmain">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/voidmain.html"><!-- qtag -->Question 11.12b</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>

Can I declare <TT>main</TT> as <TT>void</TT>,
to shut off these annoying
``main returns no value'' messages?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
No.
<TT>main</TT> must be declared as returning an <TT>int</TT>,
and as
taking either zero or two arguments,
of the appropriate types.
If you're calling <TT>exit()</TT> but still getting warnings,
you may have to insert a redundant <TT>return</TT> statement
(or use some kind
of ``not reached'' directive,
if available).
</p><p>Declaring a function as <TT>void</TT> does not merely
shut off or rearrange
warnings:
it may also result in a different

function call/return sequence,

incompatible with what the caller
(in <TT>main</TT>'s case, the C run-time startup code)
expects.

That is,
if the calling sequences for <TT>void</TT>-
and <TT>int</TT>-valued functions differ,

the startup code is going to be calling <TT>main</TT>
using
specifically the
<TT>int</TT>-valued conventions,
and if <TT>main</TT> has been improperly declared as <TT>void</TT>,
it may not
work.

(See also question <a href="faqcat6b6b.html?sec=struct#retcrash">2.18</a>.)
</p><p>(Note that
this discussion of <TT>main</TT>
pertains only to ``hosted'' implementations;
none of it applies to ``freestanding'' implementations,
which may not even have <TT>main</TT>.
However,
freestanding implementations are comparatively rare,
and if you're using one,
you probably know it.
If you've never heard of the distinction,
you're probably using a hosted implementation,
and the above rules apply.)
</p><p>Additional links:
<a href="../../ansi/sd11.html" rel=subdocument>further reading</a>
</p>



<p>References:

ISO Sec. 5.1.2.2.1, Sec. G.5.1
<br>
H&amp;S Sec. 20.1 p. 416
<br>
CT&amp;P Sec. 3.10 pp. 50-51
<hr><hr><hr>
<a name="envp">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/envp.html"><!-- qtag -->Question 11.13</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
But what about <TT>main</TT>'s third argument,
<TT>envp</TT>?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
It's a non-standard
(though common)
extension.
If you really need to access the environment
in ways beyond what the standard
<TT>getenv</TT> function provides,
though,
the global variable <TT>environ</TT> is probably
a better avenue
(though it's equally non-standard).
</p>

<p>References:

ISO Sec. G.5.1
<br>
H&amp;S Sec. 20.1 pp. 416-7
<hr><hr><hr>
<a name="voidmain3">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/voidmain3.html"><!-- qtag -->Question 11.14a</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I believe that declaring <TT>void&nbsp;main()</TT> can't fail,
since I'm calling <TT>exit</TT> instead of returning,
and anyway my operating system ignores a program's exit/return status.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
It doesn't matter whether <TT>main</TT> returns or not,
or whether anyone looks at the status;
the problem is that
when <TT>main</TT> is misdeclared,
its caller
(the runtime startup code)
may not even be able to <em>call</em> it correctly
(due to the potential clash of calling conventions;
see question <a href="faqcat7d4b.html?sec=ansi#voidmain">11.12b</a>).
</p><p>Your
operating system may ignore the exit status,
and <TT>void&nbsp;main()</TT> may work for you,
but it is not portable and not correct.

</p><p>Additional links:
<a href="../../ansi/sd11.html" rel=subdocument>further reading</a>
<hr><hr><hr>
<a name="voidmainexamp">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/voidmainexamp.html"><!-- qtag -->Question 11.14b</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
So what could go wrong?
Are there
really any
systems where <TT>void&nbsp;main()</TT> doesn't work?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
It has been reported that














programs using <TT>void&nbsp;main()</TT>
and compiled using BC++&nbsp;4.5
can crash.
Some compilers
(including



DEC C V4.1
and <TT>gcc</TT> with certain warnings enabled)
will complain about <TT>void&nbsp;main()</TT>.
</p><p>Additional links:
<a href="http://www.eskimo.com/~scs/readings/voidmain.960823.html">further reading</a>
<a href="../../ansi/sd12.html" rel=subdocument>examples</a>
<hr><hr><hr>
<a name="voidmainbooks">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/voidmainbooks.html"><!-- qtag -->Question 11.15</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
The book I've been using,
<I>C Programing
for the Compleat Idiot</I>,
always uses <TT>void&nbsp;main()</TT>.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Perhaps its author
counts himself among the target audience.
Many books unaccountably use <TT>void&nbsp;main()</TT> in examples,
and assert that it's correct.
They're
wrong,
or they're assuming that everyone writes code
for systems where it happens to work.
<hr><hr><hr>
<a name="exitvsreturn">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/exitvsreturn.html"><!-- qtag -->Question 11.16</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Is <TT>exit(status)</TT> truly equivalent
to returning the same <TT>status</TT> from <TT>main</TT>?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Yes and no.
The Standard says that
a return from the initial call to <TT>main</TT>
is equivalent to calling <TT>exit</TT>.
However,
a <TT>return</TT> from <TT>main</TT>
cannot be expected to work


if
data local to <TT>main</TT> might be needed
during cleanup;
see also question <a href="faqcat5e04.html?sec=strangeprob#crashatexit">16.4</a>.
A few
very old,
nonconforming systems
may
once have had
problems

with one or the other form.
(Finally, the
two forms are obviously not equivalent
in a recursive call to <TT>main</TT>.)
</p>

<p>References:

K&amp;R2 Sec. 7.6 pp. 163-4
<br>
ISO Sec. 5.1.2.2.3
<hr><hr><hr>
<a name="stringize">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../ansi/stringize.html"><!-- qtag -->Question 11.17</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I'm trying to use
the ANSI ``stringizing'' preprocessing operator
`<TT>#</TT>'
to insert the value of a symbolic constant into a message,
but it keeps
stringizing the macro's name rather than its
value.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
It turns out that
the definition of <TT>#</TT>
says that
it's supposed to stringize
a macro argument immediately,
without further expanding it
(if the argument happens to be
the name of
another macro).
You can use
something like the following
two-step
procedure
to force a macro to be expanded as well as
stringized:
<pre>
#define Str(x) #x
#define Xstr(x) Str(x)
#define OP plus
char *opname = Xstr(OP);
</pre>
This
code

sets <TT>opname</TT> to <TT>"plus"</TT> rather than <TT>"OP"</TT>.
(It works because
the <TT>Xstr()</TT> macro expands its argument,
and then <TT>Str()</TT> stringizes it.)
<a href="../../ansi/fn50.html" rel=subdocument>[footnote]</a>
</p><p>
An equivalent circumlocution is necessary
with the
token-pasting
operator <TT>##</TT>
when the values
(rather than the names)
of two macros are to be concatenated.
</p><p>
Note that both <TT>#</TT> and <TT>##</TT> operate