De-referencing NULL

[rahul]

#include <stdio.h>

int
main (void) {
char *p = NULL;
printf ("%c\n", *p);
return 0;
}

This snippet prints 0(compiled with DJGPP on Win XP). Visual C++ 6.0
compiles the program with diagnostics and the program crashes when
ran. gcc on Linux gives SEGMENTATION FAULT.

This looks like a bug with DJGPP. NULL can have different
representations but how come the compiler allows de-referencing NULL
without any compile time or run-time errors?

P.S : I am not discussing DJGPP. I just want to know if this behaviour
is OK with C specs?

[santosh]

santosh wrote:

rahul wrote:

>#include <stdio.h>

int
main (void) {
char *p = NULL;
printf ("%c\n", *p);
return 0;
}

This snippet prints 0(compiled with DJGPP on Win XP). Visual C++ 6.0
compiles the program with diagnostics and the program crashes when
ran. gcc on Linux gives SEGMENTATION FAULT.

This looks like a bug with DJGPP. NULL can have different
representation s but how come the compiler allows de-referencing NULL
without any compile time or run-time errors?

I have already provided the reason why no compile-time diagnostics are
required. As for runtime diagnostics/exceptions, note that the
segfaults you are getting from Windows XP (compiled with MSVC) and
Linux are a response of the operating system. DJGPP on the other hand
is designed to produce programs that run under DOS, which does not
have memory protection and hence fails to trap the access to memory
address zero.

All the above is information beyond the scope of the C Standard, which
by categorising the behaviour as undefined, allows different
implementations to do whatever makes the most sense for them and
avoids defining this complex issue. If it had defined the behaviour in
any manner, there would have been some systems which would then have
had to emulate this behaviour and hence suffer considerable
performance and implementation problems.

This is merely a special case of C allowing access beyond an object.

And the above is subtly wrong and highly misleading.

A null pointer *cannot* by definition point to anywhere and thus a
deference of a null pointer is always invalid. This has nothing to do
with the hardware or with memory addresses, but is dictated by the
semantics of C. It just so happens that on the vast majority of
implementations the value that a null pointer contains is the same as
the value for memory address zero at a bit level. Thus when a null
pointer is deferenced, the implementation interprets the value as a
memory address and attempts to read it. This is caught under some
systems and not under others.

Conceptually a null pointer is distinct from a pointer containing the
address value zero, but under many flat memory model architectures
their representations are identical and hence, in the absence of any
special interpretation (which becomes cumbersome), deferencing a null
pointer performs the same action as deferencing a pointer containing
address zero.

Recently Harald van Dijk gave an example of an implementation (I think
it was the Tendra C compiler) that interprets a null pointer as having
a value other than zero.

[Keith Thompson]

santosh <sa*********@gm ail.comwrites:
[...]

Conceptually a null pointer is distinct from a pointer containing the
address value zero, but under many flat memory model architectures
their representations are identical and hence, in the absence of any
special interpretation (which becomes cumbersome), deferencing a null
pointer performs the same action as deferencing a pointer containing
address zero.

[...]

Sort of -- except that there's not really such a thing as "the address
value zero" in C, at least not in the sense that you mean.

You can *convert* an integer value zero to a pointer type. If the
converted value happens to be a constant expression, the result is a
null pointer value, due to the special-case rule that C uses to define
null pointer constants. If it's a non-constant expression whose
current run-time value is zero, the result of the conversion is
implementation-defined, and may or may not correspond to "the address
value zero" on the underlying system, assuming such a thing is even
meaningful.

This means that converting a value of zero to a pointer type might
yield different results depending on whether the zero value is a
constant expression or not, which is a bit bizarre. But most systems
don't make this distinction because, as santosh said in text I've
snipped, most systems choose to use all-bits-zero as the null pointer
representation, avoiding the need for special-case code to handle the
special-case rule for null pointer constants. On most (but not all)
such systems, attempts to dereference a null pointer are caught with
no additional effort, since 00000000 is not a valid address.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Johannes Bauer]

Keith Thompson schrieb:

>P.S : I am not discussing DJGPP. I just want to know if this behaviour
is OK with C specs?

The behavior is undefined, which means that any behavior is ok as far
as the standard is concerned.

I've started wondering whether this is a good idea - on architectures
like the AVR, there are indeed memory-mapped I/O registers in the
address space at address 0x00. For instance on an ATmega32, writing to

*((volatile unsigned char*)0x00) = 0x00;

Would set the TWBR (Two Wire Serial Interface Bit Rate Register). Is
this undefined behaviour, too? This would then mean the language is in
some way incompatible with the architecture, which is a really weird thing.

Regards,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electron ics <47************ ***********@new s.freenet.de>

[Chris Torek]

>Keith Thompson schrieb:

>The behavior is undefined, which means that any behavior is ok as far
as the standard is concerned.

In article <i6************ @joeserver.home lan.net>
Johannes Bauer <df***********@ gmx.dewrote:

>I've started wondering whether this is a good idea -

It is, in fact, a great idea, precisely because of what you say next.

>on architectures like the AVR, there are indeed memory-mapped I/O
registers in the address space at address 0x00. For instance on an
ATmega32, writing to

*((volatile unsigned char*)0x00) = 0x00;

Would set the TWBR (Two Wire Serial Interface Bit Rate Register). Is
this undefined behaviour, too?

Undefined by the C Standard, yes.

By being left undefined in the C Standard, implementors are allowed
to define it themselves. Implementors working on the ATmega32 can
define (*(volatile unsigned char *)0) as "access the TWBR".

Had the C Standard said "this must trap" or "this must access RAM",
implementors writing implementations for the ATmega32 would *not*
have been able to give you access to the TWBR in this obvious and
simple manner.

Undefined behavior is "bad" in that, if you use it, you lose the
guarantees of the C Standard. But it is "good" in that, by leaving
it undefined, you can use non-"Standard C" in ways guaranteed by
something *other* than the C Standard. There is nothing wrong with
doing this: you just need to know that your guarantees are coming
from "Frobozz Inc ATmega32 C" and not "ISO Standard C".
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: gmail (figure it out) http://web.torek.net/torek/index.html

[Johannes Bauer]

Chris Torek schrieb:

>I've started wondering whether this is a good idea -

It is, in fact, a great idea, precisely because of what you say next.

Okay, alright, I understood what you wrote. Thank you for your
comprehensive answer!

Regards,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electron ics <47************ ***********@new s.freenet.de>

[CBFalconer]

rahul wrote:

>
#include <stdio.h>

int main (void) {
char *p = NULL;
printf ("%c\n", *p);
return 0;
}

This snippet prints 0(compiled with DJGPP on Win XP). Visual C++
6.0 compiles the program with diagnostics and the program crashes
when ran. gcc on Linux gives SEGMENTATION FAULT.

This looks like a bug with DJGPP. NULL can have different
representations but how come the compiler allows de-referencing
NULL without any compile time or run-time errors?

P.S : I am not discussing DJGPP. I just want to know if this
behaviour is OK with C specs?

No, it is not allowable to dereference the NULL pointer. Behaviour
is undetermined. The fact that DJGPP doesn't detect this fault is
a Quality of Implementation detail.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Greg Comeau]

In article <i6************ @joeserver.home lan.net>,
Johannes Bauer <df***********@ gmx.dewrote:

>Keith Thompson schrieb:

>>P.S : I am not discussing DJGPP. I just want to know if this behaviour
is OK with C specs?

The behavior is undefined, which means that any behavior is ok as far
as the standard is concerned.

I've started wondering whether this is a good idea - on architectures
like the AVR, there are indeed memory-mapped I/O registers in the
address space at address 0x00. For instance on an ATmega32, writing to

*((volatile unsigned char*)0x00) = 0x00;

Would set the TWBR (Two Wire Serial Interface Bit Rate Register). Is
this undefined behaviour, too?

It is undefined behavior.

>This would then mean the language is in
some way incompatible with the architecture, which is a really weird thing.

Not necessarily incompatible. It is not saying it must be rejected
or that it must fail, it is "just" not telling you what happens.
What it is doing then is leaving the door open to allow you to do it,
of course, along with a compiler for the platform in question.
Since C is not defining it, it's giving you a "fighting chance"
of giving you the rope on machines where you need that rope.
On those where you don't need the rope, it is still there though.
But as in the thread, on those other machines, compilers etc
can set it up for a trap, and so on.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Jack Klein]

On Mon, 04 Aug 2008 20:42:58 +0200, Johannes Bauer
<df***********@ gmx.dewrote in comp.lang.c:

Keith Thompson schrieb:

P.S : I am not discussing DJGPP. I just want to know if this behaviour
is OK with C specs?

The behavior is undefined, which means that any behavior is ok as far
as the standard is concerned.

I've started wondering whether this is a good idea - on architectures
like the AVR, there are indeed memory-mapped I/O registers in the
address space at address 0x00. For instance on an ATmega32, writing to

*((volatile unsigned char*)0x00) = 0x00;

Would set the TWBR (Two Wire Serial Interface Bit Rate Register). Is
this undefined behaviour, too? This would then mean the language is in
some way incompatible with the architecture, which is a really weird thing.

As others have already mentioned, it is of course undefined behavior,
which is not necessarily a bad thing in all contexts.

But if Atmel moved that register from address 0x00 to 0x01, or 0x08,
or indeed any other address, the result of reading from or writing to
that address would still be undefined. Any access to any hardware
device is completely undefined under the C standard, and that is
exactly as it should be.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Antoninus Twink]

On 5 Aug 2008 at 1:24, Jack Klein wrote:

On Mon, 04 Aug 2008 20:42:58 +0200, Johannes Bauer
<df*********** @gmx.dewrote in comp.lang.c:

>*((volatile unsigned char*)0x00) = 0x00;

Would set the TWBR (Two Wire Serial Interface Bit Rate Register). Is
this undefined behaviour, too? This would then mean the language is in
some way incompatible with the architecture, which is a really weird thing.

As others have already mentioned, it is of course undefined behavior,
which is not necessarily a bad thing in all contexts.

But if Atmel moved that register from address 0x00 to 0x01, or 0x08,
or indeed any other address, the result of reading from or writing to
that address would still be undefined. Any access to any hardware
device is completely undefined under the C standard, and that is
exactly as it should be.

This is complete nonsense, as you are well aware. The whole point of the
OP's query is that 0 in a pointer context is a null pointer constant,
whereas 1 and 8 are not.

[Richard Tobin]

In article <i6************ @joeserver.home lan.net>,
Johannes Bauer <df***********@ gmx.dewrote:

>I've started wondering whether this is a good idea - on architectures
like the AVR, there are indeed memory-mapped I/O registers in the
address space at address 0x00. For instance on an ATmega32, writing to

*((volatile unsigned char*)0x00) = 0x00;

Would set the TWBR (Two Wire Serial Interface Bit Rate Register). Is
this undefined behaviour, too? This would then mean the language is in
some way incompatible with the architecture, which is a really weird thing.

I'm just going to address the last sentence.

You might consider the language incompatible with the architecture if
it said anything about what happened when address 0 was accessed, but
C doesn't do that. There is no necessary connection between C's null
pointer and the architecture's address 0, though they are the same in
most implementations . In particular, there's no reason that

(volatile unsigned char*)0x00

produce the architecture address 0. It could produce, say, 0xffffffff.
The conversion of integers to pointers can involve arbitrary computation,
but null pointers can only be generated from constants, so the compiler
could do or insert code for the necessary conversion.

int x = 0;
(char *)x

is not guaranteed to produce a null pointer.

I doubt that this would be a good idea on balance, though such a compiler
might be useful for certain kinds of debugging.

-- Richard
--
Please remember to mention me / in tapes you leave behind.