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?

[Richard Tobin]

In article <9N************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

>This looks like a bug with DJGPP.

>It isn't. It's a bug in the program. It dereferences NULL.

It may not be a bug in the compiler, but it's certainly a deficiency
that it does not detect the error.

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

[Flash Gordon]

Richard Tobin wrote, On 06/08/08 13:09:

In article <9N************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

>>This looks like a bug with DJGPP.

>It isn't. It's a bug in the program. It dereferences NULL.

It may not be a bug in the compiler, but it's certainly a deficiency
that it does not detect the error.

Or a feature, providing compatibility with old compilers which did not
detect the error. Specifically with programs that are playing about with
the interrupt vector table in DOS!
--
Flash Gordon

[Richard Tobin]

In article <k2************ @news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwro te:

>It may not be a bug in the compiler, but it's certainly a deficiency
that it does not detect the error.

>Or a feature, providing compatibility with old compilers which did not
detect the error. Specifically with programs that are playing about with
the interrupt vector table in DOS!

So it's a backward-compatible deficiency.

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

[blargg]

In article <g7**********@p c-news.cogsci.ed. ac.uk>, ri*****@cogsci. ed.ac.uk
(Richard Tobin) wrote:

[...]
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.
[...]

If one needed a pointer of address 0 in such a case, say where an
architecture had a register at 0 and whose null pointer was non-zero, one
subtract 1 from a char* of address 1:

char* addr_0 = (char*) 1 - 1;

[Keith Thompson]

bl********@gish puppy.com (blargg) writes:

In article <g7**********@p c-news.cogsci.ed. ac.uk>, ri*****@cogsci. ed.ac.uk
(Richard Tobin) wrote:

>[...]
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.
[...]

If one needed a pointer of address 0 in such a case, say where an
architecture had a register at 0 and whose null pointer was non-zero, one
subtract 1 from a char* of address 1:

char* addr_0 = (char*) 1 - 1;

That's one approach. Another is to use a non-constant expression:

int non_constant_ze ro = 0;
char *addr_0 = (char*)non_cons tant_zero;

(You could even declare non_constant_ze ro as const if you wanted to
confuse your readers.)

--
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"

[santosh]

Richard Tobin wrote:

In article <k2************ @news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwro te:

>>It may not be a bug in the compiler, but it's certainly a deficiency
that it does not detect the error.

>>Or a feature, providing compatibility with old compilers which did not
detect the error. Specifically with programs that are playing about
with the interrupt vector table in DOS!

So it's a backward-compatible deficiency.

This discussion is similar to the "putc and EOF" one going on elsewhere.
The fundamental problem is NULL should ideally be an "out-of-band"
value, but because on the vast majority of architectures pointers are
implemented with the semantics of unsigned integers, and "out-of-band"
value is impossible, and hence the compulsion to use a perfectly
defined address (zero) as the internal representation of storing NULL
in a pointer. Zero is a perfectly valid memory address.

If pointers are implemented as being identical signed integers then one
could use the value -1 for NULL. Another option would be to use the
largest representable value for NULL. An address like 4294967295 is not
used as often as address zero.

[Flash Gordon]

Keith Thompson wrote, On 07/08/08 04:50:

bl********@gish puppy.com (blargg) writes:

>In article <g7**********@p c-news.cogsci.ed. ac.uk>, ri*****@cogsci. ed.ac.uk
(Richard Tobin) wrote:

>>[...]
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.
[...]

If one needed a pointer of address 0 in such a case, say where an
architecture had a register at 0 and whose null pointer was non-zero, one
subtract 1 from a char* of address 1:

char* addr_0 = (char*) 1 - 1;

That's one approach. Another is to use a non-constant expression:

int non_constant_ze ro = 0;
char *addr_0 = (char*)non_cons tant_zero;

(You could even declare non_constant_ze ro as const if you wanted to
confuse your readers.)

However, I would say the best approach is to read the examples in the
manual for that particular implementation and use whatever method they
use (which might be a non-standard header providing a suitable pointer
constant). After all, you are trying to do something non-portable so
whatever non-portable method the implementation documentation suggests
will not reduce portability.
--
Flash Gordon

[Willem]

Flash Gordon wrote:
) Keith Thompson wrote, On 07/08/08 04:50:
)That's one approach. Another is to use a non-constant expression:
)>
) int non_constant_ze ro = 0;
) char *addr_0 = (char*)non_cons tant_zero;
)>
)(You could even declare non_constant_ze ro as const if you wanted to
)confuse your readers.)
)
) However, I would say the best approach is to read the examples in the
) manual for that particular implementation and use whatever method they
) use (which might be a non-standard header providing a suitable pointer
) constant). After all, you are trying to do something non-portable so
) whatever non-portable method the implementation documentation suggests
) will not reduce portability.

Almost always, there is a header defining all the hardware addresses. This
even makes it a bit more portable should you decide to switch to a platform
with the same registers at different memory locations.

I remember on the atmels there were include files for every single chip.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[Flash Gordon]

Willem wrote, On 07/08/08 09:09:

Flash Gordon wrote:
) Keith Thompson wrote, On 07/08/08 04:50:
)That's one approach. Another is to use a non-constant expression:
)>
) int non_constant_ze ro = 0;
) char *addr_0 = (char*)non_cons tant_zero;
)>
)(You could even declare non_constant_ze ro as const if you wanted to
)confuse your readers.)
)
) However, I would say the best approach is to read the examples in the
) manual for that particular implementation and use whatever method they
) use (which might be a non-standard header providing a suitable pointer
) constant). After all, you are trying to do something non-portable so
) whatever non-portable method the implementation documentation suggests
) will not reduce portability.

Almost always, there is a header defining all the hardware addresses. This
even makes it a bit more portable should you decide to switch to a platform
with the same registers at different memory locations.

I remember on the atmels there were include files for every single chip.

I would assume that the examples in the manuals used those header files,
so that is covered by my suggestion :-)

Actually, I've come across similar things and that is one reason why I
suggested referring to the documentation for the best method to solve a
problem that cannot be solved portably.
--
Flash Gordon