The Value of NULL

[Carl]

I am reading a book on C after my introductory C course, and I noticed
that in my book it claimed that the NULL macro can be values other than
(void *)0. The book claims that NULL can be an address that cannot be
accessed, so it is possible for the hardware to catch errors. If that
is the case, would such as the following be wrong in certain environments:

int *a;
a = malloc( sizeof(int) );

if(!a)
{
printf("Unable to allocate memory!\n");
exit(1);
}

 

[James Kuyper]

I am reading a book on C after my introductory C course, and I noticed
that in my book it claimed that the NULL macro can be values other than
(void *)0. ...

NULL is a macro whose expansion must be a null pointer constant (NPC).
An NPC has just two possibilities: an integer constant expression (ICE)
with a value of 0, or an ICE converted to void*. Therefore, all of the
following are legal expansions for NULL:

0
OU
0L
'\0'
(5-5)
(0==1)

... The book claims that NULL can be an address that cannot be
accessed, so it is possible for the hardware to catch errors.

Here you appear to be confusing NULL, which is a macro, with a null
pointer value. The expansion of NULL, like any other null pointer
constant, is implicitly converted into a null pointer in some contexts.
However, null pointers are not the same thing as NULL.

Yes, null pointers can have an address that cannot be accessed. That's
equally true of (void*)0 as of (char*)(5-5).

... If that
is the case, would such as the following be wrong in certain environments:

int *a;
a = malloc( sizeof(int) );

Minor style point: it's better practice to write this as:

int *a = malloc(sizeof *a);

if(!a)
{
printf("Unable to allocate memory!\n");
exit(1);
}

You accessed the memory that contains that null pointer, but not the
memory it points at, so there is no problem.

 

[Eric Sosman]

I am reading a book on C after my introductory C course, and I noticed
that in my book it claimed that the NULL macro can be values other than
(void *)0. The book claims that NULL can be an address that cannot be
accessed, so it is possible for the hardware to catch errors. [...]

You should read Section 5 of the comp.lang.c Frequently
Asked Questions (FAQ) list at <http://www.c-faq.com/>.

 

[Chris Dollin]

I am reading a book on C after my introductory C course, and I noticed
that in my book it claimed that the NULL macro can be values other than
(void *)0. The book claims that NULL can be an address that cannot be
accessed, so it is possible for the hardware to catch errors. If that
is the case, would such as the following be wrong in certain environments:

int *a;
a = malloc( sizeof(int) );

if(!a)
{
printf("Unable to allocate memory!\n");
exit(1);
}

No, because the implementation is required to treat the test `!a`,
when `a` is a pointer, as `a == 0`, ie, `a is null`, performing
any gymnastics required.

(James has addressed your confusion of `NULL` and `the null pointer
value` elsethread.)

 

[Carl]

http://www.c-faq.com/null/ptrtest.html

Thanks for the quick replies. Its kind of hard to phrase these
questions in google searches.

I am reading a book on C after my introductory C course, and I noticed
that in my book it claimed that the NULL macro can be values other
than (void *)0. The book claims that NULL can be an address that
cannot be accessed, so it is possible for the hardware to catch
errors. [...]

You should read Section 5 of the comp.lang.c Frequently
Asked Questions (FAQ) list at <http://www.c-faq.com/>.

 

[Antoninus Twink]

Therefore, all of the following are legal expansions for NULL:

OU

I think you mean 0U.

 

[Carl]

Indeed. I searched for "The value of NULL in C" and... well, I came up
with lots of useful hits:

http://www.google.com/search?q=the+value+of+null+in+C

 

[CBFalconer]

I am reading a book on C after my introductory C course, and I
noticed that in my book it claimed that the NULL macro can be
values other than (void *)0. The book claims that NULL can be
an address that cannot be accessed, so it is possible for the
hardware to catch errors. If that is the case, would such as
the following be wrong in certain environments:

int *a;
a = malloc( sizeof(int) );

if(!a)
{
printf("Unable to allocate memory!\n");
exit(1);
}

The only thing wrong is the failure to include the necessary header
files, and the use of "exit(1)", along with the lack of a main
returning an int. 1 is not a legal parameter for exit. Use
"exit(EXIT_FAILURE);". EXIT_FAILURE is defined in stdlib.h.

 

[Carl]

You know, after reviewing my original post I also found a few things
wrong, one of which being that I posted this to a mailing list rather
than to a C compiler. Thread's over.

 

[Keith Thompson]

The only thing wrong is the failure to include the necessary header
files, and the use of "exit(1)", along with the lack of a main
returning an int. 1 is not a legal parameter for exit. Use
"exit(EXIT_FAILURE);". EXIT_FAILURE is defined in stdlib.h.

Certainly exit(EXIT_FAILURE) is more portable than exit(1), but
exit(1) isn't necessarily wrong. It might be perfectly appropriate in
system-specific code. And just what is "1 is not a legal parameter
for exit" supposed to mean? The status returned to the host
environment is implementation-defined; there's nothing illegal about
that.

As for the lack of main and of the required #includes, it was clearly
a code fragment. Complete programs are usually preferable, but in
this case the meaning was clear enough.

 

[CBFalconer]

Carl wrote: *** and top-posted - fixed ***

You know, after reviewing my original post I also found a few things
wrong, one of which being that I posted this to a mailing list rather
than to a C compiler. Thread's over.

This is not a mailing list. It is a Usenet newsgroup, which is a
much different thing. For one thing, you can start a thread, but
not end it.

If you ever return, please do not top-post. I fixed this one.
Your answer belongs after (or intermixed with) the quoted material
to which you reply, after snipping all irrelevant material. See
the following links:

<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/> (taming google)
<http://members.fortunecity.com/nnqweb/> (newusers)

 

[Flash Gordon]

I didn't think answering "The program is fine" was quite
appropriate.

So when you post (a link to) code that is non-portable because it uses a
function outside the C standard that is acceptable, but when someone
else posts code which returns an *implementation* *defined* status that
is "illegal"?

Remember that as far as the C standard is concerned your nmalloc package
has UNDEFINED behaviour because it calls sbrk.

exit(1) is portable to at least approximately the same range of
implementations that sbrk is (it is supported on DOS, Windows and Posix
as a way of returning a value that can then be checked for example by
using ERRORLEVEL, it is supported on VMS where it is a "success" value etc).

 

[Keith Thompson]

I didn't think answering "The program is fine" was quite
appropriate.

I didn't think answering with false statements was quite appropriate
either.

 

[CBFalconer]

.... snip ...

Remember that as far as the C standard is concerned your nmalloc
package has UNDEFINED behaviour because it calls sbrk.

That was an entirely different thread, and the message said that he
could attempt to adapt the program, not that he could use it
directly. Certain people with troll-like behavious snipped the
appropriate portions of the message.

 

[Beej Jorgensen]

Is it then your opinion that the truth depends on which thread
you're in?

Not in this thread, it doesn't.

-Beej

 

[Flash Gordon]

Flash Gordon wrote:
.... snip ...

That was an entirely different thread, and the message said that he
could attempt to adapt the program, not that he could use it
directly.

I know it is a different thread. that does not affect the argument.

Certain people with troll-like behavious snipped the
appropriate portions of the message.

I read your original message just fine thanks, and I don't believe that
it was distorted by snippage.

You have been REPEATEDLY claiming that code which relies on
implementation defined behaviour "does not work" even when it is
explicitly acknowledged that it relies on implementation defined
behaviour. How can that rule not also apply to your own code which
relies on UNDEFINED behaviour? In either case the code can be modified,
that is NOT something unique to your code.

 

[CBFalconer]

CBFalconer wrote:
.... snip ...

You have been REPEATEDLY claiming that code which relies on
implementation defined behaviour "does not work" even when it is
explicitly acknowledged that it relies on implementation defined
behaviour. How can that rule not also apply to your own code
which relies on UNDEFINED behaviour? In either case the code can
be modified, that is NOT something unique to your code.

But I don't present it as something that doesn't need modification.