Null pointers

[junky_fellow]

Can 0x0 be a valid virtual address in the address space
of an application ?
If it is valid, then the location pointed by a NULL pointer
is also valid and application should not receive "SIGSEGV"
( i am talking of unix machine ) while trying to read that
location.
Then how can i distinguish between a NULL pointer and an invalid
location ?
Is this essential that NULL pointer should not point to any of
the location in the virtual address space ?

If NULL pointer should not essentially point to an invalid
location, then why we should always use NULL to be location 0x0,
can we use some other location as well ?

Is this necessary that whenever an application try to access
location pointed by NULL pointer, it should be aborted by kernel
by posting some signal ?

Please i need your help, beacuse i am getting more confused
as i am reading more and more documents on NULL pointers.
thanx for any help in advance.....

[Dave Thompson]

On 6 Aug 2004 18:40:23 GMT, Chris Torek <no****@torek.net> wrote:
<much snip>

- Most implementors use all-bits-zero for internal null pointers.
It is usually the easiest thing to do, <snip> - Many machines without virtual memory, and even some with, have
ROM or RAM at physical address 0.
The IBM S/360 architecture has various special stuff in low memory,
like old and new PSW's for various interrupts, although I don't recall
if any of them are at exactly 0. And thus so must its compatible
descendants (370, 390, and "z" series) in real mode, which ISTR IBM as
usual calls by some more officious name like "translation disabled".
And for multiprocessor machines, even with virtual memory off -- or
nonexistent? were there MP 360s? I don't recall -- they have a kludge
where page zero is switched with some other page that can be different
for each processor. Bleah.

Though I don't think there was ever a C on those machines (or at all?)
before 370s and virtual memory.
- C implementations that use all-bits-zero for all their internal
null pointers *and* that have useable RAM at address 0 must
make sure not to put any C object or function at address zero,
which is typically easily achieved by putting some "non-C"
thing there, such as startup code or a "shim".

Or, on "classic" (legacy) Tandem^WCompaq^WHP NonStop, which has
separate code and data address spaces, data address 0 is always used
for data internal to the run time library, specifically a pointer to
the "run unit control block", never a user object (variable). On this
implementation if you store through null, or fetch through null and
use it as a pointer to store at or near -- e.g. (mis)use 0 as a struct
foo * * or any_t (* *)[N] -- subsequently various C runtime stuff esp.
stdio which depends on data in or more often pointed to by the RUCB
malfunctions in bizarre and sometimes spectacular ways.

- David.Thompson1 at worldnet.att.net

[Dan Pop]

In <ch*********************************@slb-newsm1.svr.pol.co.uk> Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

In article <cf**********@pita.alt.net>,
RCollins <rc***@nospam.theriver.com> wrote:

Christian Bau wrote:

> Quite possible in C90, but most definitely not in C99. In C90, the
> wording was such that in an assignment, or within an equality operator,
> and probably some cases that I forgot, a null pointer constant was
> replaced with a null pointer. (char*)0 was _not_ one if these cases and

I thought that casting constant 0 to any pointer type produced the
null pointer; is this not the case?

In C90 it was _not_ the case. There was _no_ rule in C90 that said that
casting constant 0 to any pointer type produced a null pointer.

It was implied by another rule:

If a null pointer constant is assigned to or compared for equality
to a pointer, the constant is converted to a pointer of that type.
Such a pointer, called a null pointer, is guaranteed to compare
unequal to a pointer to any object or function.

The semantics of assignment include an implicit conversion. There is no
good reason to assume that the *same* conversion, when performed
explicitly, generates a different result.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <41***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:

Mabden wrote:

... snip ...

CBFalconer just reads. I've never said that zero location can't
be system code, altho I desired it to be unreadable in C (before
my conversion). But my main point was for zero to be unwritable
(which is wrong, which is wrong, which is wrong!).

Because I have no idea what is actually at location 0 and what it
does, and no interest in finding out. I expect reading to be
non-harmful to my system.

Any good reason for such an expectation?

On most Unix systems (AIX is one of the exceptions), the behaviour is:

fangorn:~/tmp 15> cat test.c
#include <stdio.h>
#include <string.h>

int main()
{
char *p;
memset(&p, 0, sizeof p);
printf("%d\n", *p);
}
fangorn:~/tmp 16> gcc test.c
fangorn:~/tmp 17> ./a.out
Segmentation fault

Note that this is the *portable* way to access location zero. The
result of converting an integer to a pointer is implementation-defined
and need not be a mere reinterpretation of a bit pattern.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de