faqcat1f1a.html

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

<p>References:

ISO Sec. 7.1.6
<br>
Rationale Sec. 4.1.5
<hr><hr><hr>
<a name="safermacs">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../null/safermacs.html"><!-- qtag -->Question 5.6</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
If <TT>NULL</TT> were defined as
follows:
<pre>
	#define NULL ((char *)0)
</pre>
wouldn't that make function calls which pass an uncast <TT>NULL</TT> work?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
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 <TT>NULL</TT> 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
<pre>
	FILE *fp = NULL;
</pre>
could fail.
</p><p>Nevertheless,
ANSI C allows the alternate
definition
<pre>
	#define NULL ((void *)0)
</pre>
for <TT>NULL</TT>.
<a href="../../null/voidpassign.html" rel=subdocument>[footnote]</a>
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 <TT>NULL</TT> incorrectly
(e.g. when the ASCII NUL character was really intended;
see question
<a href="faqcat1f1a.html?sec=null#nullor0">5.9</a>).
See also question <a href="faqcat1f1a.html?sec=null#long0">5.7</a>.
</p><p>At any rate, ANSI function prototypes ensure that most
(though not quite all; see question <a href="faqcat1f1a.html?sec=null#null2">5.2</a>)
pointer arguments are converted correctly
when passed as function arguments,
so the question is largely moot.
</p><p>Programmers who are accustomed to
modern, ``flat'' memory architectures may
find the idea of ``different kinds of pointers''
very difficult to accept.
See question
<a href="faqcat1f1a.html?sec=null#machexamp">5.17</a>
for some


examples.
</p>
<p>References:

Rationale Sec. 4.1.5
<hr><hr><hr>
<a name="long0">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../null/long0.html"><!-- qtag -->Question 5.7</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
My vendor provides header files that <TT>#define</TT> <TT>NULL</TT> as <TT>0L</TT>.
Why?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Some programs carelessly attempt to generate null pointers
by using the <TT>NULL</TT> macro,

without casts,
in non-pointer contexts.
(Doing so is not guaranteed to work;
see questions

<a href="faqcat1f1a.html?sec=null#null2">5.2</a>
and <a href="faqcat1f1a.html?sec=null#nullreq">5.11</a>.)
On machines
which have pointers larger than integers
(such as PC compatibles in ``large'' model;
see also question <a href="faqcat1f1a.html?sec=null#machexamp">5.17</a>),
a


particular
definition of <TT>NULL</TT> such as <TT>0L</TT>
can help these incorrect programs to

work.
(<TT>0L</TT> is a perfectly valid definition of <TT>NULL</TT>;
it is an ``integral constant expression with value 0.'')

Whether it is wise to coddle incorrect programs

is debatable;
see also question <a href="faqcat1f1a.html?sec=null#safermacs">5.6</a>
and
section
<a href="faqcataae2.html?sec=style#index">17</a>.
</p>

<p>References:

Rationale Sec. 4.1.5
<br>
H&amp;S Sec. 5.3.2 pp. 121-2
<hr><hr><hr>
<a name="fcnptr">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../null/fcnptr.html"><!-- qtag -->Question 5.8</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Is <TT>NULL</TT> valid for pointers to functions?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Yes (but see question <a href="faqcatabdc.html?sec=ptrs#generic">4.13</a>).
</p>
<p>References:

ISO Sec. 6.2.2.3
<hr><hr><hr>
<a name="nullor0">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../null/nullor0.html"><!-- qtag -->Question 5.9</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
If <TT>NULL</TT> and <TT>0</TT> are equivalent
as null pointer constants,
which should I use?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Many programmers believe that <TT>NULL</TT>
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 <TT>NULL</TT>
and <TT>0</TT> is only compounded
by hiding <TT>0</TT> behind a macro,
and prefer to use unadorned <TT>0</TT> instead.
There is no one right answer.
(See also questions
<a href="faqcate034.html?sec=bool#macros">9.4</a>
and
<a href="faqcataae2.html?sec=style#stylewars">17.10</a>.)

C&nbsp;programmers must understand that
<TT>NULL</TT> and <TT>0</TT> are interchangeable
in pointer contexts,
and that an uncast <TT>0</TT> is
perfectly acceptable.
Any usage of <TT>NULL</TT>
(as opposed to <TT>0</TT>) 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 <TT>0</TT>'s from integer <TT>0</TT>'s.
</p><p>It is only in pointer contexts that <TT>NULL</TT> and 0 are equivalent.
<TT>NULL</TT> should
<em>not</em>
be used when another kind of <TT>0</TT> is required,
even though it might work,
because doing so sends the wrong stylistic message.
(Furthermore,
ANSI allows the definition of <TT>NULL</TT> to be <TT>((void&nbsp;*)0)</TT>,
which will not work
at all
in non-pointer contexts.)
In particular, do not use <TT>NULL</TT> when the ASCII

null character
(NUL)
is desired.
Provide your own definition
<pre>
	#define NUL '\0'
</pre>
if you must.
</p>

<p>References:

K&amp;R1 Sec. 5.4 pp. 97-8
<br>
K&amp;R2 Sec. 5.4 p. 102
<hr><hr><hr>
<a name="macsochange">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../null/macsochange.html"><!-- qtag -->Question 5.10</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
But wouldn't it be better to use <TT>NULL</TT>
(rather than

<TT>0</TT>),
in case the value of <TT>NULL</TT> changes,
perhaps on a machine with nonzero internal null pointers?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
No.
(Using <TT>NULL</TT> 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
<em>not</em>
the reason that <TT>NULL</TT> is used in place of <TT>0</TT>.
Once again,
the language guarantees that source-code <TT>0</TT>'s

(in pointer contexts)
generate null pointers.
<TT>NULL</TT> is used only as a stylistic convention.
See questions <a href="faqcat1f1a.html?sec=null#machnon0">5.5</a> and <a href="faqcate034.html?sec=bool#macros">9.4</a>.
<hr><hr><hr>
<a name="nullreq">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../null/nullreq.html"><!-- qtag -->Question 5.11</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I once used a compiler that wouldn't work unless <TT>NULL</TT> was
used.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
Unless the code being compiled was nonportable,
that
compiler
was probably broken.
</p><p>Perhaps the code used something like this nonportable version of an 
example from question <a href="faqcat1f1a.html?sec=null#null2">5.2</a>:
<pre>
	execl("/bin/sh", "sh", "-c", "date", NULL);	/* WRONG */
</pre>
Under a compiler which defines <TT>NULL</TT> to <TT>((void&nbsp;*)0)</TT>
(see question <a href="faqcat1f1a.html?sec=null#safermacs">5.6</a>),
this code will happen to work.
<a href="../../null/voidpcharp.html" rel=subdocument>[footnote]</a>
However,
if pointers and integers have different sizes or representations,
the (equally incorrect) code
<pre>
	execl("/bin/sh", "sh", "-c", "date", 0);	/* WRONG */
</pre>
may not work.
</p><p>Correct, portable code uses an explicit cast:
<pre>
	execl("/bin/sh", "sh", "-c", "date", (char *)NULL);
</pre>
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 <TT>NULL</TT>.
(The code fragment in question <a href="faqcat1f1a.html?sec=null#null2">5.2</a>,
which used 0 instead of <TT>NULL</TT>,
is equally correct;
see also question <a href="faqcat1f1a.html?sec=null#nullor0">5.9</a>.)
(In general, making decisions about a language based on the
behavior of one particular compiler is likely to be counterproductive.)
<hr><hr><hr>
<a name="nullptrmacro">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../null/nullptrmacro.html"><!-- qtag -->Question 5.12</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>

I use the preprocessor macro
<pre>
#define Nullptr(type) (type *)0</pre>

to help me build null pointers of the correct type.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
This trick,
though popular
and superficially attractive,

does not buy much.
It is not needed in assignments
or
comparisons; see question
<a href="faqcat1f1a.html?sec=null#null2">5.2</a>.
(It does not even save keystrokes.)

See also questions
<a href="faqcate034.html?sec=bool#booltype">9.1</a>
and
<a href="faqcat204f.html?sec=cpp#slm">10.2</a>.
<hr><hr><hr>
<a name="varieties">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../null/varieties.html"><!-- qtag -->Question 5.13</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
This is strange.
<TT>NULL</TT> is guaranteed to be <TT>0</TT>, but the null pointer is not?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
When the term ``null'' or ``<TT>NULL</TT>'' is casually used,
one of several things may be meant:
<OL><li>The conceptual null pointer,
the abstract language
concept
defined in question
<a href="faqcat1f1a.html?sec=null#null1">5.1</a>.
It is implemented with...
<li>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...
<li>The null pointer constant,
which is a constant integer 0

<a href="../../null/fn22.html" rel=subdocument>[footnote]</a>
(see question
<a href="faqcat1f1a.html?sec=null#null2">5.2</a>).
It is often hidden behind...
<li>The <TT>NULL</TT> macro,
which is <TT>#define</TT>d to be <TT>0</TT>
(see question <a href="faqcat1f1a.html?sec=null#macro">5.4</a>).
Finally,
as red herrings,
we have...
<li>The ASCII null character (NUL),
which does have all bits zero,
but has no
necessary
relation to the null pointer except in name;
and...
<li>The ``null string,''
which is another name for the empty string 
(<TT>""</TT>).
Using
the
term ``null string'' can be confusing in C,
because
an empty string
involves a null (<TT>'\0'</TT>) character,
but <em>not</em> a null pointer,
which brings us full circle...
</OL></p><p>In other words, to paraphrase
the White Knight's description of his song in
<I>Through the Looking-Glass</I>,
the name of the null pointer is ``<TT>0</TT>'',
but the name of the
null pointer is called ``<TT>NULL</TT>''
(and we're not sure what the null pointer
<em>is</em>).
</p><p>This
document
uses the phrase ``null pointer''
(in lower case)
for sense&nbsp;1,

the token ``<TT>0</TT>''
or the phrase ``null pointer constant''
for sense&nbsp;3,
and the capitalized word ``<TT>NULL</TT>''
for sense&nbsp;4.<a href="../../null/precise.html" rel=subdocument>[footnote]</a>
</p><p>Additional links:
<a href="../../null/bull.html" rel=subdocument>mnemonic device</a>
</p>
<p>References:

H&amp;S Sec. 1.3 p. 325
<br>
<I>Through the Looking-Glass</I>,
chapter VIII.

<hr><hr><hr>
<a name="confusion">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../null/confusion.html"><!-- qtag -->Question 5.14</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Why is there so much confusion surrounding null pointers?
Why do these questions come up so often?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
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 (<TT>NULL</TT>)
may seem to suggest
that the value could change
some day,
or
on some weird machine.