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?

[Gordon Burditt]

>#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.

Whatever the implementation does or doesn't do here, it's not a bug
per the C standard. You may argue that it is a quality-of-implementation
issue that the program fails to delete its own source code.

>NULL can have different
representations but how come the compiler allows de-referencing NULL
without any compile time or run-time errors?

A C compiler is not required to diagnose a de-reference of NULL at
either compile time or run time. Undefined behaviour can include
fetching zero or ignoring write attempts, or it can include fetching
zero or ignoring write attempts except when the boss or customer
is watching during a demonstration, then catching his tie on fire.

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

No matter what happens in this situation, it's OK with the C specs.
No possible behavior is forbidden, even if it violates the laws of
physics.

[santosh]

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?

The behaviour is defined to be undefined. Here is the relevant bit from
n1256.pdf:

6.5.3.2

4 The unary * operator denotes indirection. If the operand points to a
function, the result is a function designator; if it points to an
object, the result is an lvalue designating the object. If the operand
has type ??pointer to type??, the result has type ??type??. If an
invalid value has been assigned to the pointer, the behavior of the
unary * operator is undefined.87)

Part of the indicated footnote (which is not normative):

Among the invalid values for dereferencing a pointer by the unary *
operator are a null pointer, [ ... ]

Since no constraint is violated, the implementation is not obliged to
emit a diagnostic, though one would be useful. But it's hard to do this
in all possible cases.

[Keith Thompson]

rahul <ra*********@gmail.comwrites:

#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?

The behavior is undefined, which means that any behavior is ok as far
as the standard is concerned. If your implementation produced no
diagnostics but made demons fly out of your nose, it might violate the
laws of physics, but it wouldn't violate the standard.

--
Keith Thompson (The_Other_Keith) 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"

[Richard Heathfield]

rahul said:

#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.

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

NULL can have different
representations but how come the compiler allows de-referencing NULL
without any compile time or run-time errors?

Removing the programmer's ability to parade his stupidity necessarily
entails removing his ability to be clever when necessary.

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

Yes. The Standard doesn't mandate what must happen when the programmer does
this particular kind of stupid thing, so any behaviour is acceptable.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

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?

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.

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

[Richard Bos]

rahul <ra*********@gmail.comwrote:

char *p = NULL;
printf ("%c\n", *p);

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.

It isn't. Dereferencing a null pointer has undefined behaviour. Crashing
is legal; printing a message and then crashing is legal; and so is
printing any random value, as if it were a normal dereference.

Richard

[Nick Keighley]

On 4 Aug, 07:24, rahul <[e-mail]:

#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?

I've even used a compiler that made it a command line option.
You could choose if dereferencing NULL crashed or not.
Why you would want this option is a good question...

--
Nick Keighley

[Jean-Marc Bourguet]

Nick Keighley <ni******************@hotmail.comwrites:

On 4 Aug, 07:24, rahul <[e-mail]:

#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?

I've even used a compiler that made it a command line option.
You could choose if dereferencing NULL crashed or not.
Why you would want this option is a good question...

The most probable reason is compatibility with a previous implementation
for which it was the (perhaps even documented) behaviour?

Yours,

--
Jean-Marc

[santosh]

Nick Keighley wrote:

On 4 Aug, 07:24, rahul <[e-mail]:

>#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?

I've even used a compiler that made it a command line option.
You could choose if dereferencing NULL crashed or not.
Why you would want this option is a good question...

To be notified of invalid deferences (as NULL always is) when the
underlying OS/hardware does not catch it?

[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
representations 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*********@gmail.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_Keith) 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.electronics <47***********************@news.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.homelan.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.electronics <47***********************@news.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.homelan.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.learn.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.homelan.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.

[Richard Tobin]

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

>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.invalidwrote:

>>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.ukwrote:

>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**********@pc-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********@gishpuppy.com (blargg) writes:

In article <g7**********@pc-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_zero = 0;
char *addr_0 = (char*)non_constant_zero;

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

--
Keith Thompson (The_Other_Keith) 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.ukwrote:

>>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********@gishpuppy.com (blargg) writes:

>In article <g7**********@pc-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_zero = 0;
char *addr_0 = (char*)non_constant_zero;

(You could even declare non_constant_zero 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_zero = 0;
) char *addr_0 = (char*)non_constant_zero;
)>
)(You could even declare non_constant_zero 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_zero = 0;
) char *addr_0 = (char*)non_constant_zero;
)>
)(You could even declare non_constant_zero 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