By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,656 Members | 1,327 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,656 IT Pros & Developers. It's quick & easy.

Null pointers

P: n/a
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.....
Nov 14 '05 #1
Share this Question
Share on Google+
102 Replies


P: n/a
junky_fellow wrote:
Can 0x0 be a valid virtual address in the address space
of an application ?
Yes.
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.
No. If 0 is a valid (C-accessible) address on the machine, then
0 is not a legal representation for a pointer value.
Then how can i distinguish between a NULL pointer and an invalid
location ?
The null (not NULL) pointer tests equal to a integer constant
expression with value 0. Invalid locations don't.
Is this essential that NULL pointer should not point to any of
the location in the virtual address space ?
It's essential that the null (not NULL) pointer not point to
any C-accessible location.
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 ?
NULL has nothing to do with location 0 (except by coincidence on
most machines). You're confusing the internal representation of
the null pointer with the internal representation of the integer
0 - and the implementation is free to use some *other* representaion
of the null pointer, such as the address of some byte in the run-time
system that no C program can legally see.
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 ?
No. That's nice, but it's not required.
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.....


Don't try and understand what's implemented; try and understand
the rules.

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html
Nov 14 '05 #2

P: n/a
In article <8c**************************@posting.google.com >,
junky_fellow <ju**********@yahoo.co.in> wrote:
Can 0x0 be a valid virtual address in the address space
of an application ?


Historically, and in almost all C implementations, null pointers are
just pointers corresponding to the address 0. In these
implementations, if you put the integer zero into a location whose
size is the same as a pointer, and then treat that location as a
pointer, you will be doing exactly the same thing as if you had a real
null pointer.

The C standards don't require things to work like that though. They
make null pointers more abstract, like nil in Lisp or null in Java.
Null pointers *could* be represented so that they corresponded to the
address 0x12345678. In that case, the implementation would have to be
careful never to put a real object at address 0x12345678, and an
assignment like "int *foo = 0" or "int *foo = NULL" would have to be
compile to code that put the value 0x12345678 into foo's location.
Setting the location to zero by some means such as memset or calloc
would not work.

All this is quite separate from whether dereferencing a null pointer
causes some kind of exception. On modern machines with virtual memory
it's usual to unmap that page containing the null pointer address
(which in practice is page 0 - an implementation that represented null
pointers as 0x12345678 could unmap that page instead). This wasn't
always the case: a lot of early Vax C code assumed that null pointers
pointed to a byte containing zero, so that null pointers and empty
strings were interchangable. This practice was eradicated once people
ported their programs to machines like the early Suns, which did unmap
page 0.

-- Richard
Nov 14 '05 #3

P: n/a
"junky_fellow" <ju**********@yahoo.co.in> wrote in message
news:8c**************************@posting.google.c om...
Can 0x0 be a valid virtual address in the address space
of an application ?


No. Zero is never a valid location in C.

--
Mabden
Nov 14 '05 #4

P: n/a
Mabden <mabden@sbc_global.net> scribbled the following:
"junky_fellow" <ju**********@yahoo.co.in> wrote in message
news:8c**************************@posting.google.c om...
Can 0x0 be a valid virtual address in the address space
of an application ?
No. Zero is never a valid location in C.


It's not a valid pointer value, but it can be a valid memory address. As
has been stated, pointer values need not correspond exactly to memory
addresses.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
Nov 14 '05 #5

P: n/a
Chris Dollin <ke**@hpl.hp.com> writes:
junky_fellow wrote:
Can 0x0 be a valid virtual address in the address space
of an application ?


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


No. If 0 is a valid (C-accessible) address on the machine, then
0 is not a legal representation for a pointer value.


It depends on what you mean by "valid".

(I'm going to use the term "all-bits-zero" to refer to memory address
zero, since a literal 0 can refer to some other address.)

If an implementation's representation of a null pointer is
all-bits-zero, no C object (either declared or allocated via malloc())
can exist at that address. Any attempt to dereference a null pointer
invokes undefined behavior. However, it's entirely possible (for a
given implementation) that there is an addressible memory location at
address all-bits-zero, and that a C program is able to access it
by dereferencing a null pointer.

Dereferencing a null pointer invokes undefined behavior; that can
include fetching a value stored at address all-bits-zero, trapping, or
making demons fly out your nose.

An implementation is obliged not to store a visible C object at the
address it reserves for null pointers; it's not obliged to trap
attempts to dereference a null pointer.

(Actually that's not quite true; there could be a visible object
named, say, __FOO__ at the null address, perhaps wit the specific
purpose of preventing any other object from occupying that address.
I don't know of any implementation that actually does this.)

To the OP: read sections 4 and 5 of the C FAQ if you haven't already.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #6

P: n/a
"Mabden" <mabden@sbc_global.net> wrote in message news:<xY********************@newssvr29.news.prodig y.com>...
"junky_fellow" <ju**********@yahoo.co.in> wrote in message
news:8c**************************@posting.google.c om...
Can 0x0 be a valid virtual address in the address space
of an application ?


No. Zero is never a valid location in C.


Chapter and verse? AFAIK there are several architectures where
zero is a valid location, and you can safely read and write from it.
Nov 14 '05 #7

P: n/a
>Can 0x0 be a valid virtual address in the address space
of an application ?
Yes.
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.
The declaration:

or
char *p = 0;

is not guaranteed to put the bit pattern 0xdeadbeef into p, even
on 32-bit machines, or the pattern 0xdeadbeef0xdeadbeef on 64-bit
machines. But it might.
Then how can i distinguish between a NULL pointer and an invalid
location ?
The code:
if (p == 0) { ... } /* integer constant zero */
or
if (p == NULL) { ... } /* integer constant zero */

might generate the assembly code:

cmpl r4,#0xdeadbeef (Compare p with the bit pattern deadbeef)
bne .L5
...
..L5:

While the code:

int i = 0;

if (p == i) { ... } /* i is *NOT* an integer constant zero */

might gnerate the assembly code:

cmpl r4, #0 (Compare p with the bit pattern 00000000 )
bne .L5
...
..L5:
Is this essential that NULL pointer should not point to any of
the location in the virtual address space ?
Lots of older implementations without virtual memory used a NULL
pointer bit pattern of all-bits-zero and address 0 was a valid
address in the virtual address space (e.g. you could read, and even
write, it without having anything nasty happen like SIGSEGV.)
However, the thing at address was NOT a valid C object. Sometimes
it was startup code. Sometimes it was a zero byte, so code like:
printf("%s", NULL);
wouldn't print garbage, and also to prevent address 0 from being
assigned as a valid C object. I prefer the implementation where
the above printf() produces a list of cusswords.
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 ?
If you (a compiler writer) use a NULL pointer value of all-bits-zero,
you don't have to be so careful about translating "an integer
constant with value 0 in a pointer context" to a NULL pointer
representation with a different bit pattern. This takes care in
writing the compiler, it may make code slightly bigger and slower,
and it causes bogus bug reports from people trying to compile sloppy
code. And in assembly language, testing for zero is likely to be
faster. Probably most important, making the NULL pointer all-bits-zero
lets crap code (there's a LOT of it out there!) run and cuts down
on your tech support costs.
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 ?
No. But it's a really, really good idea. So is deleting the
offending source code (all copies), but I haven't seen anyone do
that yet. And an application should be coded assuming that it
*MIGHT* be aborted if it does that.
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.....


Ignore the documents written by any US political party about
NULL pointers. They are just trying to drum up support to
tax them. And don't bid on any null pointers for sale on Ebay.

Gordon L. Burditt
Nov 14 '05 #8

P: n/a

"Old Wolf" <ol*****@inspire.net.nz> wrote
No. Zero is never a valid location in C.


Chapter and verse? AFAIK there are several architectures where
zero is a valid location, and you can safely read and write from it.

This code is undefined

char *ptr = 0;

*ptr = 1;

it may segfault, or it may write the value 1 to location 0 in memory, or it
may cause little green eleves to appear on screen.

This code is OK

void foo(char *ptr)
{
assert(ptr != 0);
}

char ch;

foo(&ch);

as long as ch is a valid object, the address may never evaluate to 0 (NULL).

This code is implementation defined

int x = 0;
char *ptr = (char *) x;

*ptr = 1;

if your platform allows writes to a location represented by all bits zero,
then it is correct. However most platforms won't allow this.
Nov 14 '05 #9

P: n/a
On Tue, 3 Aug 2004 23:35:14 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote in comp.lang.c:

"Old Wolf" <ol*****@inspire.net.nz> wrote
No. Zero is never a valid location in C.


Chapter and verse? AFAIK there are several architectures where
zero is a valid location, and you can safely read and write from it.

This code is undefined

char *ptr = 0;

*ptr = 1;

it may segfault, or it may write the value 1 to location 0 in memory, or it
may cause little green eleves to appear on screen.

This code is OK

void foo(char *ptr)
{
assert(ptr != 0);
}

char ch;

foo(&ch);

as long as ch is a valid object, the address may never evaluate to 0 (NULL).

This code is implementation defined

int x = 0;
char *ptr = (char *) x;

*ptr = 1;

if your platform allows writes to a location represented by all bits zero,
then it is correct. However most platforms won't allow this.


No, actually several common desk top operating systems that you happen
to be familiar with do not allow this. Unfortunately your desk top
chauvinism is totally incorrect as far as the vast majority of
platforms that run C is concerned.

On most processors, microcontrollers, and DSPs, that have C
implementations, which number orders of magnitude more than your desk
top platforms, you can access memory at address "all bits 0". Whether
there is any utility to doing so, and what might happen if you try to
write there, is another story. But a read access is totally benign,
the memory location exists, and the result is whatever it contains.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #10

P: n/a


Jack Klein wrote:
On Tue, 3 Aug 2004 23:35:14 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote in comp.lang.c:

"Old Wolf" <ol*****@inspire.net.nz> wrote
No. Zero is never a valid location in C.

Chapter and verse? AFAIK there are several architectures where
zero is a valid location, and you can safely read and write from it.

This code is undefined

char *ptr = 0;

*ptr = 1;

it may segfault, or it may write the value 1 to location 0 in memory, or it
may cause little green eleves to appear on screen.

This code is OK

void foo(char *ptr)
{
assert(ptr != 0);
}

char ch;

foo(&ch);

as long as ch is a valid object, the address may never evaluate to 0 (NULL).

This code is implementation defined

int x = 0;
char *ptr = (char *) x;

*ptr = 1;

if your platform allows writes to a location represented by all bits zero,
then it is correct. However most platforms won't allow this.

No, actually several common desk top operating systems that you happen
to be familiar with do not allow this. Unfortunately your desk top
chauvinism is totally incorrect as far as the vast majority of
platforms that run C is concerned.


Er .. did't you just say the same thing Malcolm said? Or am I reading
you wrong?
On most processors, microcontrollers, and DSPs, that have C
implementations, which number orders of magnitude more than your desk
top platforms, you can access memory at address "all bits 0". Whether
there is any utility to doing so, and what might happen if you try to
write there, is another story. But a read access is totally benign,
the memory location exists, and the result is whatever it contains.


True; there are also machines where all-bits-0 is an invalid address,
and even machines (extinct, to my knowledge) where very low addresses
(including all-bits-0) represented actual register locations. However,
on all of these machines, it is _still_ up to the compiler to map a
constant 0 value to the NULL address (however it may be represented
internally).

Cheers,
Ron
--
Ron Collins
Nov 14 '05 #11

P: n/a
"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...
"Mabden" <mabden@sbc_global.net> wrote in message

news:<xY********************@newssvr29.news.prodig y.com>...
"junky_fellow" <ju**********@yahoo.co.in> wrote in message
news:8c**************************@posting.google.c om...
Can 0x0 be a valid virtual address in the address space
of an application ?


No. Zero is never a valid location in C.


Chapter and verse? AFAIK there are several architectures where
zero is a valid location, and you can safely read and write from it.


K&R2 pg. 102 "C guarantees that zero is never a valid address for data..."

--
Mabden
Nov 14 '05 #12

P: n/a
"Mabden" <mabden@sbc_global.net> writes:
"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...
"Mabden" <mabden@sbc_global.net> wrote in message

news:<xY********************@newssvr29.news.prodig y.com>...
"junky_fellow" <ju**********@yahoo.co.in> wrote in message
news:8c**************************@posting.google.c om...
> Can 0x0 be a valid virtual address in the address space
> of an application ?

No. Zero is never a valid location in C.


Chapter and verse? AFAIK there are several architectures where
zero is a valid location, and you can safely read and write from it.


K&R2 pg. 102 "C guarantees that zero is never a valid address for data..."


My copy of K&R2 isn't handy, but I presume "zero" refers to a null
pointer (which can be represented in source by a literal 0), not
necessarily to an all-bits-zero address.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #13

P: n/a
go***********@burditt.org (Gordon Burditt) wrote in message news:<ce********@library2.airnews.net>...
Can 0x0 be a valid virtual address in the address space
of an application ?


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


The declaration:

or
char *p = 0;

is not guaranteed to put the bit pattern 0xdeadbeef into p, even
on 32-bit machines, or the pattern 0xdeadbeef0xdeadbeef on 64-bit
machines. But it might.
Then how can i distinguish between a NULL pointer and an invalid
location ?


The code:
if (p == 0) { ... } /* integer constant zero */
or
if (p == NULL) { ... } /* integer constant zero */

might generate the assembly code:

cmpl r4,#0xdeadbeef (Compare p with the bit pattern deadbeef)
bne .L5
...
.L5:

While the code:

int i = 0;

if (p == i) { ... } /* i is *NOT* an integer constant zero */

might gnerate the assembly code:

cmpl r4, #0 (Compare p with the bit pattern 00000000 )
bne .L5
...
.L5:
Is this essential that NULL pointer should not point to any of
the location in the virtual address space ?


Lots of older implementations without virtual memory used a NULL
pointer bit pattern of all-bits-zero and address 0 was a valid
address in the virtual address space (e.g. you could read, and even
write, it without having anything nasty happen like SIGSEGV.)
However, the thing at address was NOT a valid C object. Sometimes
it was startup code. Sometimes it was a zero byte, so code like:
printf("%s", NULL);
wouldn't print garbage, and also to prevent address 0 from being
assigned as a valid C object. I prefer the implementation where
the above printf() produces a list of cusswords.
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 ?


If you (a compiler writer) use a NULL pointer value of all-bits-zero,
you don't have to be so careful about translating "an integer
constant with value 0 in a pointer context" to a NULL pointer
representation with a different bit pattern. This takes care in
writing the compiler, it may make code slightly bigger and slower,
and it causes bogus bug reports from people trying to compile sloppy
code. And in assembly language, testing for zero is likely to be
faster. Probably most important, making the NULL pointer all-bits-zero
lets crap code (there's a LOT of it out there!) run and cuts down
on your tech support costs.
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 ?


No. But it's a really, really good idea. So is deleting the
offending source code (all copies), but I haven't seen anyone do
that yet. And an application should be coded assuming that it
*MIGHT* be aborted if it does that.
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.....


Ignore the documents written by any US political party about
NULL pointers. They are just trying to drum up support to
tax them. And don't bid on any null pointers for sale on Ebay.

Gordon L. Burditt


thanx a lot to all of you for the valuable comments and help....
Nov 14 '05 #14

P: n/a
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Mabden" <mabden@sbc_global.net> writes:
"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...
"Mabden" <mabden@sbc_global.net> wrote in message news:<xY********************@newssvr29.news.prodig y.com>...
> "junky_fellow" <ju**********@yahoo.co.in> wrote in message
> news:8c**************************@posting.google.c om...
> > Can 0x0 be a valid virtual address in the address space
> > of an application ?
>
> No. Zero is never a valid location in C.

Chapter and verse? AFAIK there are several architectures where
zero is a valid location, and you can safely read and write from it.


K&R2 pg. 102 "C guarantees that zero is never a valid address for

data..."
My copy of K&R2 isn't handy, but I presume "zero" refers to a null
pointer (which can be represented in source by a literal 0), not
necessarily to an all-bits-zero address.


That would make a "pres" out of "u" and "me".
It refers to a location. There is no location zero in memory in C for data.

Where the hell is Dan Pop?!! Back me up, Dude.

--
Mabden
Nov 14 '05 #15

P: n/a
"Mabden" <mabden@sbc_global.net> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Mabden" <mabden@sbc_global.net> writes: [...]
K&R2 pg. 102 "C guarantees that zero is never a valid address
for data..."


My copy of K&R2 isn't handy, but I presume "zero" refers to a null
pointer (which can be represented in source by a literal 0), not
necessarily to an all-bits-zero address.


That would make a "pres" out of "u" and "me".
It refers to a location. There is no location zero in memory in C for data.

Where the hell is Dan Pop?!! Back me up, Dude.


You must be very brave to utter his name.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #16

P: n/a
Keith Thompson wrote:

"Mabden" <mabden@sbc_global.net> writes:

Where the hell is Dan Pop?!! Back me up, Dude.


You must be very brave to utter his name.

I don't know why he keeps saying that. I explained all this to him once
on CLC++, but the message didn't get across.

He needs to engage his brain.


Brian Rodenborn
Nov 14 '05 #17

P: n/a
On Tue, 3 Aug 2004 23:35:14 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:

"Old Wolf" <ol*****@inspire.net.nz> wrote
> No. Zero is never a valid location in C.


Chapter and verse? AFAIK there are several architectures where
zero is a valid location, and you can safely read and write from it.

This code is undefined

char *ptr = 0;

*ptr = 1;

<snip>

This is only because 0 is converted to the internal value for
representing a NULL-pointer, isn't it?

Hmm let's see, how could we...

char *ptr = 0; /* ptr is a NULL pointer */
char **p = &ptr;

*p ^= *p; /* I am hoping to have cleared every bit of ptr */

If every bit of ptr is cleared and it has the value '0', it is no
longer necessarily a NULL pointer, is it?
--
aib

ISP e-mail accounts are good for receiving spam.
Nov 14 '05 #18

P: n/a

In article <H7**************@newssvr29.news.prodigy.com>, "Mabden" <mabden@sbc_global.net> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Mabden" <mabden@sbc_global.net> writes:

K&R2 pg. 102 "C guarantees that zero is never a valid address for
data..."

K&R2 is not the standard. It does not specify the C language. It
describes it with considerable fidelity, but not perfectly; it
contains errors.[1]
My copy of K&R2 isn't handy, but I presume "zero" refers to a null
pointer (which can be represented in source by a literal 0), not
necessarily to an all-bits-zero address.

It's not K&R's finest moment. Here's a bit more context:

If not, alloc must return some signal that no space is left. C
guarantees that zero is never a valid address for data, so a return
value of zero can be used to signal an abnormal event, in this case,
no space.

From the context it's clear that in this instance they're referring to
a pointer value - what's returned by their alloc() function. However,
the text fails to make clear that this does not apply to the actual
internal representation of an address. The use of "address" here is
infelicitous - it's either wrong or misleading. IMO this should be
added to the errata list.
That would make a "pres" out of "u" and "me".
It refers to a location. There is no location zero in memory in C for data.


Either the text is incorrect or you are misreading it. It's not
clear from the text itself which is the case. (If Dennis is reading
this thread, maybe he'll tell us what the intent of this sentence was.)

In C, *there is no relationship between a pointer value and the address
to which it refers*. In every C implementation, of course, there must
be some such relationship - but it certainly need not be as simple as
"pointer value is an address". There are extant conforming C implemen-
tations where that is not the case. And so while a pointer value of 0
must not refer to the location of any object in C, an object can exist
at address 0. A pointer to that object will not have value 0; that is
all.
1. http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html

--
Michael Wojcik mi************@microfocus.com

Painful lark, labouring to rise!
The solemn mallet says:
In the grave's slot
he lies. We rot. -- Basil Bunting
Nov 14 '05 #19

P: n/a

"RCollins" <rc***@nospam.theriver.com> wrote
if your platform allows writes to a location represented by all bits zero,then it is correct. However most platforms won't allow this.

No, actually several common desk top operating systems that you happen
to be familiar with do not allow this. Unfortunately your desk top
chauvinism is totally incorrect as far as the vast majority of
platforms that run C is concerned.


Er .. did't you just say the same thing Malcolm said? Or am I reading
you wrong?

I really don't understand the attitude. Of course what I meant was "the
platform that the OP is using probably won't allow this", but that sounds
rather patronising, as if people who don't write for PCs (which includes
myself) are in a superior category. There are of course lots of small
embedded systems out there, and it is probably technically correct to say
"more platforms" allow writes to memory location 0. However the accustion of
"desktop chauvanism" is ridiculous.

Nov 14 '05 #20

P: n/a
Orhan Kavrakoglu <ga*******@ttnet.net.tr> writes:
On Tue, 3 Aug 2004 23:35:14 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:
"Old Wolf" <ol*****@inspire.net.nz> wrote

> No. Zero is never a valid location in C.

Chapter and verse? AFAIK there are several architectures where
zero is a valid location, and you can safely read and write from it.
This code is undefined

char *ptr = 0;

*ptr = 1;

<snip>

This is only because 0 is converted to the internal value for
representing a NULL-pointer, isn't it?


Right. (It's more accurate to say "null pointer"; NULL is a macro
that expands to a "null pointer constant", and it exists only in
source.)
Hmm let's see, how could we...

char *ptr = 0; /* ptr is a NULL pointer */
Right.
char **p = &ptr;

*p ^= *p; /* I am hoping to have cleared every bit of ptr */
There's not much point in creating something that points to ptr. The
above might as well be written as:

char *ptr = 0;
p ^= p; /* illegal */

but that's still incorrect. You can't apply the bitwise xor operator
to a pointer.
If every bit of ptr is cleared and it has the value '0', it is no
longer necessarily a NULL pointer, is it?


Correct (though it will be on many implementations).

Here's a cleaner way to do what you're trying to do:

#include <string.h>
...
char *ptr = 0;
/*
* ptr is a null pointer
*/
memset(&ptr, 0, sizeof(ptr));
/*
* ptr is all-bits-zero; it may or may not be a null pointer
*/

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #21

P: n/a
Orhan Kavrakoglu wrote:

On Tue, 3 Aug 2004 23:35:14 +0100, "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:

"Old Wolf" <ol*****@inspire.net.nz> wrote

> No. Zero is never a valid location in C.

Chapter and verse? AFAIK there are several architectures where
zero is a valid location, and you can safely read and write from it.

This code is undefined

char *ptr = 0;

*ptr = 1;

<snip>

This is only because 0 is converted to the internal value for
representing a NULL-pointer, isn't it?

Hmm let's see, how could we...

char *ptr = 0; /* ptr is a NULL pointer */
char **p = &ptr;

*p ^= *p; /* I am hoping to have cleared every bit of ptr */

If every bit of ptr is cleared and it has the value '0', it is no
longer necessarily a NULL pointer, is it?


(*p) is an expression of type pointer to char.
Bitwise operations are undefined on pointer types.

int main(void)
{
char *ptr = 0;/* ptr is a null pointer */
size_t n = sizeof ptr;

while (n--) {
((unsigned char*)&ptr)[n] = 0;
}
/*
** The bits of ptr are cleared and it's value is undefined,
** it is no longer necessarily a null pointer.
*/
return 0;
}

--
pete
Nov 14 '05 #22

P: n/a
"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...
Keith Thompson wrote:

"Mabden" <mabden@sbc_global.net> writes:

Where the hell is Dan Pop?!! Back me up, Dude.


You must be very brave to utter his name.

I don't know why he keeps saying that. I explained all this to him once
on CLC++, but the message didn't get across.

He needs to engage his brain.

Brian Rodenborn


Fools are always brave; it goes with the territory. And Brian assures me I
am a fool (thanks for that Brian, I think the world of your people skills
and I'm sure you have many loving friends).

<engaging brain, opening mouth, foot at the ready...>
So, you are saying that (on some mythical machine) I could have an array a[]
that lives at location 0000:0000 of memory and point to it with ptr = &a and
ptr would not be a NULL pointer? I'm not sure I can get behind that. If
nothing else, the compiler (or linker or loader, whatever) should disallow
storing at memory location 0.

Also, you are saying that 0 can live anywhere in memory and ptr = 0 (as in
char *ptr = 0) would be NULL. This part I get, and agree with.
<disengaging overheated gears, cooling with beer>

--
Mabden
Nov 14 '05 #23

P: n/a


Mabden wrote:
"Default User" <fi********@boeing.com.invalid> wrote in message
news:41***************@boeing.com.invalid...
Keith Thompson wrote:
"Mabden" <mabden@sbc_global.net> writes:
Where the hell is Dan Pop?!! Back me up, Dude.

You must be very brave to utter his name.

I don't know why he keeps saying that. I explained all this to him once
on CLC++, but the message didn't get across.

He needs to engage his brain.

Brian Rodenborn

Fools are always brave; it goes with the territory. And Brian assures me I
am a fool (thanks for that Brian, I think the world of your people skills
and I'm sure you have many loving friends).

<engaging brain, opening mouth, foot at the ready...>
So, you are saying that (on some mythical machine) I could have an array a[]
that lives at location 0000:0000 of memory and point to it with ptr = &a and
ptr would not be a NULL pointer? I'm not sure I can get behind that. If


However, it is correct. On some machines, physical address 0 is a valid
memory location (IIRC, the old CSC machines used lower addresses
(including 0) to access the registers). However, the compiler is
required to map a *constant* 0 value to the NULL pointer. (Even if the
mapping stores a completely different bit pattern into the pointer
variable.
nothing else, the compiler (or linker or loader, whatever) should disallow
storing at memory location 0.
The compiler will handle mapping the "address" you store into a pointer
into actual physical memory addresses. There is no requirement that the
value you "see" in your source code is the actual physical memory
address used by the operating system. Think of old DOS segmented memory
addresses where there were several (in-code) representations for a
single physical memory address.

Also, you are saying that 0 can live anywhere in memory and ptr = 0 (as in
char *ptr = 0) would be NULL. This part I get, and agree with.
<disengaging overheated gears, cooling with beer>


Cheers,
Ron
--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasle"

Nov 14 '05 #24

P: n/a
"Mabden" <mabden@sbc_global.net> writes:
[silliness snipped]
<engaging brain, opening mouth, foot at the ready...>
So, you are saying that (on some mythical machine) I could have an
array a[] that lives at location 0000:0000 of memory and point to it
with ptr = &a and ptr would not be a NULL pointer?
Yes (but please use the phrase "null pointer", not "NULL pointer";
NULL is a macro). I'm assuming that your 0000:0000 notation refers to
an all-bits-zero representation.
I'm not sure I can get behind that. If nothing else, the compiler
(or linker or loader, whatever) should disallow storing at memory
location 0.
Why should it?

Despite what K&R2 says on page 102, C says nothing special about an
all-bits-zero address. The only special address defined by the
language is the null pointer, which may or may not be represented as
all-bits-zero. (The wording in K&R2, as far as I can tell, is
consistent with a requirement that null pointers always being
represented as all-bits-zero. The standard itself is not, though of
course a given implementation is allowed to represent null pointers as
all-bits-zero if it chooses).
Also, you are saying that 0 can live anywhere in memory and ptr = 0 (as in
char *ptr = 0) would be NULL. This part I get, and agree with.
<disengaging overheated gears, cooling with beer>


0 is a null pointer constant, as is any integer constant expression
with the value 0, or such an expression cast to void*. Converting a
null pointer constant to any pointer type yields a null pointer, which
is guaranteed to compare unequal to a pointer to any object or
function.

In my opinion, the standard isn't quite as clear as it should be about
things that occur in source vs. things that exist at run time. A
"null pointer constant" is a construct that appears only in C source,
and is interpreted by the compiler. NULL is a macro that expands to a
null pointer constant; again, it appears only in C source. A "null
pointer" is a particular pointer value that can exist when a program
is running (and the source may no longer even exist).

Here's something that might clarify things a bit (or not).

Suppose you're designing a programming language. You need a distinct
pointer value that doesn't point to any object, to be used for things
like indicating that a memory allocation failed, marking the end of a
linked list, etc. Call this value a "nil pointer". You don't want
programmers to care how a "nil pointer" is represented (it might be
0xdeadbeef on one platform, 0xffffffff on another), so you have a
keyword "nil" to represent a nil pointer value:

//
// This is not C.
//
char *ptr = malloc(42);
if (ptr == nil) printf("malloc failed\n");

You can think of the keyword "nil" as a "nil pointer constant".

Now you have a nice clean language. Pointers and integers are two
entirely separate things, and there's no reason anyone should confuse
"nil" (a pointer value) with "zero" (an integer value).

Now you get some feedback from your customers. They complain that
"nil" takes too long to type; they want to use a literal 0 to indicate
a nil pointer value. You give in to their demands. But is "0"
equivalent to "1-1" or "0x0"? It turns out that the cleanest way to
make this work is to say that any integer constant expression with the
value 0, or such an expression cast to void*, is a "nil pointer
constant" (in addition to the existing "nil" keyword).

You release the new language specification, but there are still
complaints. Users don't want "nil" to be a keyword, since they want
to use it as an identifier. So in the next revision of your language,
you remove the "nil" keyword; a "nil pointer constant" is *just* an
integer constant expression with the value 0, or such an expression
cast to void*. You grumble that the users' complaints have messed up
your nice clean design; there'll probably need to be an entire section
in the FAQ just to explain this. And while you're at it, you change
the terminology a bit: "nil pointer" becomes "null pointer", and "nil
pointer constant" becomes "null pointer constant". And you add a NULL
macro that expands to a null pointer constant.

And now your new language is C.

(Incidentally, this is not how C actually evolved. There never was a
"nil" keyword; I'm fairly sure the use of 0 as a null pointer constant
goes back to the beginning, if not farther.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #25

P: n/a
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:
"Old Wolf" <ol*****@inspire.net.nz> wrote
No. Zero is never a valid location in C.


Chapter and verse? AFAIK there are several architectures where
zero is a valid location, and you can safely read and write from it.

This code is undefined

char *ptr = 0;

*ptr = 1;


What has that got to do with the location zero?

When you assign '0' to a pointer in C, you get a null pointer,
not a pointer to the location zero. (Of course, on some architectures
those two things are the same, but many architectures are different).
Nov 14 '05 #26

P: n/a
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Mabden" <mabden@sbc_global.net> writes:
[silliness snipped]
<engaging brain, opening mouth, foot at the ready...>
So, you are saying that (on some mythical machine) I could have an
array a[] that lives at location 0000:0000 of memory and point to it
with ptr = &a and ptr would not be a NULL pointer?
Yes (but please use the phrase "null pointer", not "NULL pointer";
NULL is a macro). I'm assuming that your 0000:0000 notation refers to
an all-bits-zero representation.


That is what I mean, yes, as it was a popular notion in Windows programming
denoting segment:offset. I will use "null" to mean location 0 in memory
(0000:0000, or 0:0 for short), as in the very first addressable location
possible on the machine.

NULL is a macro, I agree, for basically (char *)0. This would be a zero
somewhere in memory that the program stores upon startup and compares
various pointers to, so if NULL happens to point to 1234:4321, and I set
"ptr1 = ptr2 = NULL" then both pointers would point to 1234:4321. Any
allocation or function that returns NULL would be passing the address
1234:4321, and the program would consider that to mean the allocation
failed, or the pointer has not been initialized.

I think these things are distinct cases. My point was that null, ie: 0:0, is
considered an invalid location for data. Furthermore, I believe it is
"guaranteed" to be invalid for data in C. When I state that belief, I
sometimes get told I am wrong. I only have the K&R to go on. I do not own
any reference to the "Standard this that or the other". But, didn't the K&R
come first? To make a religious reference, there was a Bible, then a New
Testament, then the Book of Mormon. I feel like I am looking at the Bible,
and getting quotes from the Book of Mormon telling me I'm wrong. "We have a
new way of doing it now!" "You aren't up to the new standard..." But I sit
back and look at MY gospel, and say, "Know, you are wrong! And your standard
is wrong if you are telling me the truth about what it says."

If the new standard says that location 0:0 is available for data storage,
then it is your standard that is wrong. Any insults to my character
nonwithstanding, that is "the way it was" and I think should be "the way it
is". It matters not at all how many people in a room decided differently.
0:0 is the true null pointer - nothing may be stored or removed from 0:0.
I'm not sure I can get behind that. If nothing else, the compiler
(or linker or loader, whatever) should disallow storing at memory
location 0.


Why should it?


Because it is the law. Why can't you travel at the speed of light?
Despite what K&R2 says on page 102, C says nothing special about an
all-bits-zero address. The only special address defined by the
language is the null pointer, which may or may not be represented as
all-bits-zero. (The wording in K&R2, as far as I can tell, is
consistent with a requirement that null pointers always being
represented as all-bits-zero. The standard itself is not, though of
course a given implementation is allowed to represent null pointers as
all-bits-zero if it chooses).
See above.
In my opinion, the standard isn't quite as clear as it should be about
things that occur in source vs. things that exist at run time. A
"null pointer constant" is a construct that appears only in C source,
and is interpreted by the compiler. NULL is a macro that expands to a
null pointer constant; again, it appears only in C source. A "null
pointer" is a particular pointer value that can exist when a program
is running (and the source may no longer even exist).
And my point is that the one, true null pointer, regardless of hardware is
location 0:0 in memory on whatever architechure you use. The NULL macro may
be implementation dependant, but C _guarantees_ that if you point a pointer
at location 0:0, you are pointing at an invalid location, and no reading or
writing is allowed. It is the "Ultimate Null". Praise Zero!

Here's something that might clarify things a bit (or not).

Not.

--
Mabden
Nov 14 '05 #27

P: n/a
ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote in message news:<ce***********@pc-news.cogsci.ed.ac.uk>...
In article <8c**************************@posting.google.com >,
junky_fellow <ju**********@yahoo.co.in> wrote:
Can 0x0 be a valid virtual address in the address space
of an application ?


Historically, and in almost all C implementations, null pointers are
just pointers corresponding to the address 0. In these
implementations, if you put the integer zero into a location whose
size is the same as a pointer, and then treat that location as a
pointer, you will be doing exactly the same thing as if you had a real
null pointer.

The C standards don't require things to work like that though. They
make null pointers more abstract, like nil in Lisp or null in Java.
Null pointers *could* be represented so that they corresponded to the
address 0x12345678. In that case, the implementation would have to be
careful never to put a real object at address 0x12345678, and an
assignment like "int *foo = 0" or "int *foo = NULL" would have to be
compile to code that put the value 0x12345678 into foo's location.
Setting the location to zero by some means such as memset or calloc
would not work.

All this is quite separate from whether dereferencing a null pointer
causes some kind of exception. On modern machines with virtual memory
it's usual to unmap that page containing the null pointer address
(which in practice is page 0 - an implementation that represented null
pointers as 0x12345678 could unmap that page instead). This wasn't
always the case: a lot of early Vax C code assumed that null pointers
pointed to a byte containing zero, so that null pointers and empty
strings were interchangable. This practice was eradicated once people
ported their programs to machines like the early Suns, which did unmap
page 0.

-- Richard


If on some implementation address 0x12345678 represent a null pointer,
and address 0x0 is a valid address,
then if in my code i deliberately trying to compare some address
with 0x0 ( a valid address ), isn't this wrong on compiler side to
replace this 0x0 with its internal representation on null pointer?
(although i was trying to compare with some valid location)
Or i should never use hard coded address values except NULL
for pointer comparisons ?
Nov 14 '05 #28

P: n/a
In article <8c**************************@posting.google.com >,
ju**********@yahoo.co.in (junky_fellow) wrote:
If on some implementation address 0x12345678 represent a null pointer,
and address 0x0 is a valid address,
then if in my code i deliberately trying to compare some address
with 0x0 ( a valid address ), isn't this wrong on compiler side to
replace this 0x0 with its internal representation on null pointer?
(although i was trying to compare with some valid location)
Or i should never use hard coded address values except NULL
for pointer comparisons ?


How do you do that comparison?

Let's say you write

char* p = malloc (100);

and the call succeeds. "p == NULL" and "p == 0" will both be false.
However, it can be true that all the bits in p are zero on this
implementation.

If you write

int i = 0;
char* q = (char *) i;

then the C99 Standard guarantees that q is a null pointer. On this
implementation it means q will point to address 0x12345678 and it will
not be equal to p. Unlike most current compilers, a compiler for this
implementation will have to produce real code to cast from int to char*.
If int and char* have the same size and alignment, then you could try to
write

* (int *) &q = 0;

to set q to a null pointer. This will work on many implementations but
not on this one; it is indeed undefined behavior.
Nov 14 '05 #29

P: n/a
"Mabden" <mabden@sbc_global.net> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Mabden" <mabden@sbc_global.net> writes:
[silliness snipped]
<engaging brain, opening mouth, foot at the ready...>
So, you are saying that (on some mythical machine) I could have an
array a[] that lives at location 0000:0000 of memory and point to it
with ptr = &a and ptr would not be a NULL pointer?
Yes (but please use the phrase "null pointer", not "NULL pointer";
NULL is a macro). I'm assuming that your 0000:0000 notation refers to
an all-bits-zero representation.


That is what I mean, yes, as it was a popular notion in Windows programming
denoting segment:offset. I will use "null" to mean location 0 in memory
(0000:0000, or 0:0 for short), as in the very first addressable location
possible on the machine.


C uses the term "null pointer" with a very specific meaning. It is,
among other things, the value returned by a failing malloc() and the
value of of argv[argc]. It is not, I repeat not, necessarily
represented as all-bits-zero (though it can be and often is).

In the context of the C programming language, using the term "null" to
refer to an all-bits-zero address is only going to cause confusion.
NULL is a macro, I agree, for basically (char *)0.
Not quite. NULL expands to an an implementation-defined null pointer
constant (C99 7.17p3). A null pointer constant is an integer constant
expression with the value 0, or such an expression cast to type void*
(C99 6.3.2.2p3). (NULL was probably defined as (char*)0 on some
pre-ANSI implementations, but that's invalid in current C.)
This would be a zero somewhere in memory that the program stores
upon startup and compares various pointers to, so if NULL happens to
point to 1234:4321, and I set "ptr1 = ptr2 = NULL" then both
pointers would point to 1234:4321. Any allocation or function that
returns NULL would be passing the address 1234:4321, and the program
would consider that to mean the allocation failed, or the pointer
has not been initialized.
I'd say that the phrase "a zero somewhere in memory" is a bit
misleading, and there's nothing that's necessarily stored upon
startup, but that's basically correct.
I think these things are distinct cases. My point was that null, ie:
0:0, is considered an invalid location for data. Furthermore, I
believe it is "guaranteed" to be invalid for data in C. When I state
that belief, I sometimes get told I am wrong. I only have the K&R to
go on. I do not own any reference to the "Standard this that or the
other". But, didn't the K&R come first? To make a religious
reference, there was a Bible, then a New Testament, then the Book of
Mormon. I feel like I am looking at the Bible, and getting quotes
from the Book of Mormon telling me I'm wrong. "We have a new way of
doing it now!" "You aren't up to the new standard..." But I sit back
and look at MY gospel, and say, "Know, you are wrong! And your
standard is wrong if you are telling me the truth about what it
says."
Sorry, but the language really is defined by the ISO standard.
(There's some dispute about whether the C90 or C99 standard is
currently more important, but they're consistent with each other in
this particular area.) If K&R2 conflicts with the standard, K&R2 is
in error. This isn't a religious issue; Kernighan and Ritchie
themselves would tell you the same thing. Take a look at the errata
list at <http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html>.

My copy of K&R2 isn't handy at the moment, but I was looking at it
earlier today. The text on page 102 is a tutorial, not a reference.
There is a language reference in Appendix A. Look up "null pointer
constant" in the index. Read the section of Appendix A that discusses
null pointer constants. It does not say anything about an
all-bits-zero address.
If the new standard says that location 0:0 is available for data storage,
then it is your standard that is wrong. Any insults to my character
nonwithstanding, that is "the way it was" and I think should be "the way it
is". It matters not at all how many people in a room decided differently.
0:0 is the true null pointer - nothing may be stored or removed from 0:0.
I don't recall insulting your character; if I did, it was unintentional.

An implementation in which the all-bits-zero address is available for
data storage can be (and in which a null pointer is represented as,
say, all-bits-one) can be perfectly conforming.
I'm not sure I can get behind that. If nothing else, the compiler
(or linker or loader, whatever) should disallow storing at memory
location 0.


Why should it?


Because it is the law. Why can't you travel at the speed of light?


There is no such law.

[...] And my point is that the one, true null pointer, regardless of
hardware is location 0:0 in memory on whatever architechure you
use. The NULL macro may be implementation dependant, but C
_guarantees_ that if you point a pointer at location 0:0, you are
pointing at an invalid location, and no reading or writing is
allowed. It is the "Ultimate Null". Praise Zero!


No, it isn't. The only basis for this is a single ambiguous statement
in K&R2. Appendix A of K&R2 and the ISO standard (both C90 and C99)
are perfectly clear on this point; there is nothing special about an
all-bits-zero pointer.
Here's something that might clarify things a bit (or not).

Not.


Ok, try section 5 of the C FAQ.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #30

P: n/a
kal
mw*****@newsguy.com (Michael Wojcik) wrote in message news:<ce********@news3.newsguy.com>...
It's not K&R's finest moment. Here's a bit more context:

If not, alloc must return some signal that no space is left. C
guarantees that zero is never a valid address for data, so a return
value of zero can be used to signal an abnormal event, in this case,
no space.

From the context it's clear that in this instance they're referring to
a pointer value - what's returned by their alloc() function. However,
the text fails to make clear that this does not apply to the actual
internal representation of an address. The use of "address" here is
infelicitous - it's either wrong or misleading. IMO this should be
added to the errata list.


That may be so but let us not be hasty.

Here are some passages from C99.

6.3.2.3 Pointers

3 An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer
constant. If a null pointer constant is converted to a
pointer type, the resulting pointer, called a null pointer,
is guaranteed to compare unequal to a pointer to any object
or function.

4 Conversion of a null pointer to another pointer type yields
a null pointer of that type. Any two null pointers shall
compare equal.

5 An integer may be converted to any pointer type. Except as
previously specified, the result is implementation-defined,
might not be correctly aligned, might not point to an entity
of the referenced type, and might be a trap representation.

6 Any pointer type may be converted to an integer type. Except
as previously specified, the result is implementation-defined.
If the result cannot be represented in the integer type, the
behavior is undefined. The result need not be in the range of
values of any integer type.
Nov 14 '05 #31

P: n/a
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
In article <8c**************************@posting.google.com >,
ju**********@yahoo.co.in (junky_fellow) wrote:
If on some implementation address 0x12345678 represent a null pointer,
and address 0x0 is a valid address,
then if in my code i deliberately trying to compare some address
with 0x0 ( a valid address ), isn't this wrong on compiler side to
replace this 0x0 with its internal representation on null pointer?
If you write

int i = 0;
char* q = (char *) i;

then the C99 Standard guarantees that q is a null pointer.


Oh? C&V, please. AFAICT it guarantees nothing of the sort; in fact, it
suggests (albeit in a footnote) that q _should_ have the value
0x00000000 if possible, and on junky_fellow's hypothetical platform that
would definitely not be a null pointer.

OTOH, if you did this

char *q=0;

or even, more superfluously,

char *q=(char *)0;

then q would be a null pointer, since 0 is a null pointer constant, and
both assignment to and casting to a pointer object are pointer contexts.

Richard
Nov 14 '05 #32

P: n/a
"Mabden" <mabden@sbc_global.net> wrote:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Mabden" <mabden@sbc_global.net> writes:
So, you are saying that (on some mythical machine) I could have an
array a[] that lives at location 0000:0000 of memory and point to it
with ptr = &a and ptr would not be a NULL pointer?

The very fact that you have an array at that location means that it
cannot possibly be a null pointer; the null pointer is guaranteed not
ever to point at any object.
Yes (but please use the phrase "null pointer", not "NULL pointer";
NULL is a macro). I'm assuming that your 0000:0000 notation refers to
an all-bits-zero representation.
That is what I mean, yes, as it was a popular notion in Windows programming
denoting segment:offset. I will use "null" to mean location 0 in memory
(0000:0000, or 0:0 for short), as in the very first addressable location
possible on the machine.


Then you still do not get it. Null pointers _need not_ point to the
lowest existing location in memory.
NULL is a macro, I agree, for basically (char *)0.
No, it isn't.
This would be a zero somewhere in memory
No, it isn't.
that the program stores upon startup and compares
various pointers to, so if NULL happens to point to 1234:4321, and I set
"ptr1 = ptr2 = NULL" then both pointers would point to 1234:4321.
Almost. But not quite.
I think these things are distinct cases. My point was that null, ie: 0:0,
From this point on, your point is invalid, since null _need not_ be 0:0.
is considered an invalid location for data. Furthermore, I believe it is
"guaranteed" to be invalid for data in C.
Your beliefs are immaterial; only the Standard counts.
When I state that belief, I sometimes get told I am wrong. I only have the K&R to go on. I do not own
any reference to the "Standard this that or the other". But, didn't the K&R
come first?
So bloody what? Anglo-Saxon came before English, but when you check your
spelling, do you use the OED, or the DOE?
To make a religious reference,
Please don't. It only makes you sound like a prat.
"We have a new way of doing it now!" "You aren't up to the new standard..."
But I sit back and look at MY gospel, and say, "Know, you are wrong! And
your standard is wrong if you are telling me the truth about what it says."


Then, to put it bluntly, you are an idiot, and you'll never program in
C. In the light of this, all the rest of your post is unimportant.

Basically, you cannot be taught; you cannot be reasoned with; you are
not worth our attention. Welcome to the killfile.

Richard
Nov 14 '05 #33

P: n/a
Christian Bau <ch***********@cbau.freeserve.co.uk> writes:
[...]
If you write

int i = 0;
char* q = (char *) i;

then the C99 Standard guarantees that q is a null pointer. On this
implementation it means q will point to address 0x12345678 and it will
not be equal to p. Unlike most current compilers, a compiler for this
implementation will have to produce real code to cast from int to char*.


Um, no. The standard guarantees that a null pointer constant,
converted to a pointer type, results in a null pointer, but i is not a
null pointer constant. The value of q will be the
implementation-defined result of converting the int value 0 to char*;
this is typically all-bits-zero even if a null pointer is 0x12345678.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #34

P: n/a
ju**********@yahoo.co.in (junky_fellow) writes:
[...]
If on some implementation address 0x12345678 represent a null pointer,
and address 0x0 is a valid address,
then if in my code i deliberately trying to compare some address
with 0x0 ( a valid address ), isn't this wrong on compiler side to
replace this 0x0 with its internal representation on null pointer?
No, it's required.

The confusion is caused by the fact that we're using "0x0" in two
different senses. When you say that 0x0 is a valid address, you mean
(I presume) that an address whose representation is all-bits-zero is
valid -- but if 0x0 appears in a pointer context in C program source,
it refers to a null pointer, however that's represented. (That's why
I've been carefully using the phrase "all-bits-zero" in this thread.)
(although i was trying to compare with some valid location)
Or i should never use hard coded address values except NULL
for pointer comparisons ?


You can use NULL or a literal 0 to refer to a null pointer; they're
equivalent. If you want to use some other numeric value for a
pointer, you're in system-specific territory, and you'd better know
what you're doing.

Read section 5 of the C FAQ if you haven't already.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #35

P: n/a
In article <41****************@news.individual.net>,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
In article <8c**************************@posting.google.com >,
ju**********@yahoo.co.in (junky_fellow) wrote:
If on some implementation address 0x12345678 represent a null pointer,
and address 0x0 is a valid address,
then if in my code i deliberately trying to compare some address
with 0x0 ( a valid address ), isn't this wrong on compiler side to
replace this 0x0 with its internal representation on null pointer?

If you write

int i = 0;
char* q = (char *) i;

then the C99 Standard guarantees that q is a null pointer.


Oh? C&V, please. AFAICT it guarantees nothing of the sort; in fact, it
suggests (albeit in a footnote) that q _should_ have the value
0x00000000 if possible, and on junky_fellow's hypothetical platform that
would definitely not be a null pointer.


1. Converting a null pointer constant to a pointer type yields a null
pointer. (BTW in an assignment char* q = 0; there is an actual
conversion from int to char*; this rule guarantees that the result is a
null pointer).

2. The result of conversion from integer to pointer type is
implementation defined, in other words, the result is defined.

3. The result of converting an integer value of zero is defined because
of (2), so far we know nothing about the result, but it will always be
the same because it is defined. In the special case that the integer
value of zero happens to be a constant integer expression, (1)
guarantees that the result is a null pointer. Since the result is always
the same, and sometimes a null pointer, it is always a null pointer.
Nov 14 '05 #36

P: n/a
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk> writes:
[...]
If you write

int i = 0;
char* q = (char *) i;

then the C99 Standard guarantees that q is a null pointer. On this
implementation it means q will point to address 0x12345678 and it will
not be equal to p. Unlike most current compilers, a compiler for this
implementation will have to produce real code to cast from int to char*.


Um, no. The standard guarantees that a null pointer constant,
converted to a pointer type, results in a null pointer, but i is not a
null pointer constant. The value of q will be the
implementation-defined result of converting the int value 0 to char*;
this is typically all-bits-zero even if a null pointer is 0x12345678.


The implementation-defined result of the conversion must be a null
pointer if the int value 0 happens to be a null pointer constant. In
other words, the implementation is not free to define conversion from
int to char* in completely arbitrary ways.

In some cases, a value of zero must be converted to a null pointer. But
a conversion just converts values, it doesn't know about any syntactical
details how the value was derived; to the conversion a zero that happens
to be a null pointer constant and a zero that happens to be the value of
an int variable are the same. The result cannot be sometimes a null
pointer and sometimes not a null pointer. So in both cases the
conversion must give the same result, which must be a null pointer.
Nov 14 '05 #37

P: n/a
Christian Bau wrote:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk> writes:
[...]
If you write

int i = 0;
char* q = (char *) i;

then the C99 Standard guarantees that q is a null pointer.
Um, no. The standard guarantees that a null pointer constant,
converted to a pointer type, results in a null pointer,
but i is not a null pointer constant.
The implementation-defined result of the conversion must be a null
pointer if the int value 0 happens to be a null pointer constant.


No.
The ordinary rules of conversion don't apply to
char *q = 0;
The assignment of a null pointer constant,
to a pointer object, is a special case.

int i = 0;
char* q = (char *)i;
is just implementation defined, and that's all that there is to it.

--
pete
Nov 14 '05 #38

P: n/a
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
In article <41****************@news.individual.net>,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
In article <8c**************************@posting.google.com >,
ju**********@yahoo.co.in (junky_fellow) wrote:

> If on some implementation address 0x12345678 represent a null pointer,
> and address 0x0 is a valid address,
> then if in my code i deliberately trying to compare some address
> with 0x0 ( a valid address ), isn't this wrong on compiler side to
> replace this 0x0 with its internal representation on null pointer?
If you write

int i = 0;
char* q = (char *) i;

then the C99 Standard guarantees that q is a null pointer.


Oh? C&V, please. AFAICT it guarantees nothing of the sort; in fact, it
suggests (albeit in a footnote) that q _should_ have the value
0x00000000 if possible, and on junky_fellow's hypothetical platform that
would definitely not be a null pointer.


1. Converting a null pointer constant to a pointer type yields a null
pointer.


Irrelevant, since there are two conversions in that snippet: one in
which an integral constant zero is converted to an int value, and one in
which an int value is converted to a pointer value. Neither of these
involve a null pointer constant in a pointer context.
2. The result of conversion from integer to pointer type is
implementation defined, in other words, the result is defined.
Yes, but not necessarily a null pointer.
3. The result of converting an integer value of zero is defined because
of (2), so far we know nothing about the result, but it will always be
the same because it is defined.
Not necessarily. It may be defined as "the current user segment, with
the integer value as the offset" - with the current user segment
changing from program run to program run.
In the special case that the integer
value of zero happens to be a constant integer expression,


That makes about as much sense as "in the case that the person you're
talking to is a photograph of your brother". A constant integer
expression is a compile-time feature. An object with a value is a
run-time feature. The latter can never be the former.

Again: the exception is for compile-time, literal constant expressions
_alone_. Not for run-time values.

Richard
Nov 14 '05 #39

P: n/a
Keith Thompson <ks***@mib.org> wrote in message news:<ln************@nuthaus.mib.org>...
ju**********@yahoo.co.in (junky_fellow) writes:
[...]
If on some implementation address 0x12345678 represent a null pointer,
and address 0x0 is a valid address,
then if in my code i deliberately trying to compare some address
with 0x0 ( a valid address ), isn't this wrong on compiler side to
replace this 0x0 with its internal representation on null pointer?


No, it's required.

The confusion is caused by the fact that we're using "0x0" in two
different senses. When you say that 0x0 is a valid address, you mean
(I presume) that an address whose representation is all-bits-zero is
valid -- but if 0x0 appears in a pointer context in C program source,
it refers to a null pointer, however that's represented. (That's why
I've been carefully using the phrase "all-bits-zero" in this thread.)
(although i was trying to compare with some valid location)
Or i should never use hard coded address values except NULL
for pointer comparisons ?


You can use NULL or a literal 0 to refer to a null pointer; they're
equivalent. If you want to use some other numeric value for a
pointer, you're in system-specific territory, and you'd better know
what you're doing.

Read section 5 of the C FAQ if you haven't already.


thanx...
Nov 14 '05 #40

P: n/a
Mabden wrote:
Fools are always brave; it goes with the territory. And Brian assures me I
am a fool (thanks for that Brian, I think the world of your people skills
and I'm sure you have many loving friends).


Please quote some post where I called you a fool. I don't believe I did
anything of sort, or even came close to it.

Brian Rodenborn
Nov 14 '05 #41

P: n/a

"Mabden" <mabden@sbc_global.net> wrote

NULL is a macro, I agree, for basically (char *)0.
If you look in your standard headers, you could easily find the line
#define NULL ((void *) 0)
My point was that null, ie: 0:0, is considered an invalid location for data. Furthermore, I believe it is "guaranteed" to be invalid for data in C.

It is not guaranteed by the standard.
In practical terms, malloc() will never return a pointer with all bits zero,
and no item in the stack or in global memory will be all bits zero either.
This is because the lowest location in memory is always special in some way,
and even if it wasn't it would be natural to use all bits zero for the null
pointer.
However this doesn't necessarily mean that you cannot force a pointer to be
all bits zero, and then read and write to it. For instance if the lowest
address in memory happens to be used by a fast machine instruction, but is
left spare by the compiler, then storing an integer in it could merely hog a
slot that an assembly programmer could put to better use. It won't
necessarily prevent the program from working.
Nov 14 '05 #42

P: n/a

In article <a5**************************@posting.google.com >, k_*****@yahoo.com (kal) writes:
mw*****@newsguy.com (Michael Wojcik) wrote in message news:<ce********@news3.newsguy.com>...
[re K&R2 p 120]

From the context it's clear that in this instance they're referring to
a pointer value - what's returned by their alloc() function. However,
the text fails to make clear that this does not apply to the actual
internal representation of an address. The use of "address" here is
infelicitous - it's either wrong or misleading. IMO this should be
added to the errata list.
That may be so but let us not be hasty.


Nor was I, when I composed that message.
Here are some passages from C99.


Indeed they are, and they agree with me. If you feel they do not,
perhaps you should have explained why, rather than merely quoting
them without comment.

--
Michael Wojcik mi************@microfocus.com

Shakespeare writes bombast and knows it; Mr Thomas writes bombast and
doesn't. That is the difference. -- Geoffrey Johnson
Nov 14 '05 #43

P: n/a
In article <CV**************@newssvr29.news.prodigy.com>,
Mabden <mabden@sbc_global.net> wrote:
And my point is that the one, true null pointer, regardless of hardware is
location 0:0 in memory on whatever architechure you use.


The idea that addresses consist of a segment and offset is just a
feature of some architectures. Even on the most common architecture
that uses that feature - the x86 - most current operating systems
provide a linear address space in which segments are irrelevant to
almost all programmers.

-- Richard
Nov 14 '05 #44

P: n/a
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:41****************@news.individual.net...
"Mabden" <mabden@sbc_global.net> wrote:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Mabden" <mabden@sbc_global.net> writes:
> So, you are saying that (on some mythical machine) I could have an
> array a[] that lives at location 0000:0000 of memory and point to it
> with ptr = &a and ptr would not be a NULL pointer?
The very fact that you have an array at that location means that it
cannot possibly be a null pointer; the null pointer is guaranteed not
ever to point at any object.
Yes (but please use the phrase "null pointer", not "NULL pointer";
NULL is a macro). I'm assuming that your 0000:0000 notation refers to
an all-bits-zero representation.


That is what I mean, yes, as it was a popular notion in Windows programming denoting segment:offset. I will use "null" to mean location 0 in memory
(0000:0000, or 0:0 for short), as in the very first addressable location
possible on the machine.


Then you still do not get it. Null pointers _need not_ point to the
lowest existing location in memory.


Of course I get that they don't "need" to point to location zero. Do you
understand that? I gave an example where NULL was pointing to 0x12344321. I
get that. NULL or null pointer or whatever does not need to point at
location zero. See, I get it. That's not my point.

My point is that in addition to the NULL or null of whatever you want to
call the thing, separately, and different from that issue, is that location
zero in memory should not be able to store data in a C program.

And assuming a prat is a bad thing to be, I'll have to say you seem like as
well, for your constantly turning the argument off-course with all the
harping on the null pointer issue which we all agree on, even me.

--
Mabden
Nov 14 '05 #45

P: n/a
"Richard Tobin" <ri*****@cogsci.ed.ac.uk> wrote in message
news:ce**********@pc-news.cogsci.ed.ac.uk...
In article <CV**************@newssvr29.news.prodigy.com>,
Mabden <mabden@sbc_global.net> wrote:
And my point is that the one, true null pointer, regardless of hardware islocation 0:0 in memory on whatever architechure you use.


The idea that addresses consist of a segment and offset is just a
feature of some architectures. Even on the most common architecture
that uses that feature - the x86 - most current operating systems
provide a linear address space in which segments are irrelevant to
almost all programmers.


No kidding. It is just a way of expressing location zero in memory, as I
explained in the bit you snipped. I am not talking about any particular
architecture. I am talking about any machine that runs a C program.

--
Mabden
Nov 14 '05 #46

P: n/a
In article <fz**************@newssvr29.news.prodigy.com>,
Mabden <mabden@sbc_global.net> wrote:
No kidding. It is just a way of expressing location zero in memory, as I
explained in the bit you snipped.


In a segmented architecture, "location zero" may not mean anything at
all. In a non-segmented architecture, "0:0" is meaningless. You're
just used to x86s and think it's a natural notation, when in fact it's
completely architecture-specific.

-- Richard
Nov 14 '05 #47

P: n/a
In article <uw**************@newssvr29.news.prodigy.com>,
"Mabden" <mabden@sbc_global.net> wrote:
Of course I get that they don't "need" to point to location zero. Do you
understand that? I gave an example where NULL was pointing to 0x12344321. I
get that. NULL or null pointer or whatever does not need to point at
location zero. See, I get it. That's not my point.

My point is that in addition to the NULL or null of whatever you want to
call the thing, separately, and different from that issue, is that location
zero in memory should not be able to store data in a C program.
There is nothing special about location 0, or location 1, or location 2,
or location 3 and so on and so on.

In many C implementations, any hardware pointer that the implementation
could use must point _somewhere_, so the location that a null pointer
points to would be special in that it cannot be used for holding C
objects. But for example on an 80286 implementation using segmented
pointers, the null pointer would most likely be represented by a segment
of 0 and an offset of 0, and on that hardware this combination doesn't
point _anywhere_. Not only does a null pointer not point to any C
object, it doesn't point anywhere at all.
And assuming a prat is a bad thing to be, I'll have to say you seem like as
well, for your constantly turning the argument off-course with all the
harping on the null pointer issue which we all agree on, even me.

Nov 14 '05 #48

P: n/a
On Wed, 04 Aug 2004 21:05:18 GMT, Keith Thompson <ks***@mib.org>
wrote:

<snip>
p ^= p; /* illegal */ <snip>Here's a cleaner way to do what you're trying to do:
memset(&ptr, 0, sizeof(ptr));


*smack on the forehead*

Yeah, that's what I meant. I know the xor operation is illegal on
pointers, but I couldn't think of memset. Let's see now, 999 more
smacks on the forehead before I can explain hypothetical situations
with legal code.
--
aib

ISP e-mail accounts are good for receiving spam.
Nov 14 '05 #49

P: n/a
"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:
[...]
In practical terms, malloc() will never return a pointer with all
bits zero, and no item in the stack or in global memory will be all
bits zero either. This is because the lowest location in memory is
always special in some way, and even if it wasn't it would be
natural to use all bits zero for the null pointer.


As you know, malloc() will return a pointer with all bits zero if the
allocation fails and that happens to be the representation of a null
pointer.

Having said that, you're assuming that all-bits-zero is the lowest
location in memory. If addresses are treated as signed integers,
all-bits-zero is right in the middle of the address space, and it's
quite likely that something could be allocated there. (I have no idea
whether this applies to any real systems.)

In any case, 99+% of the time there's no need to care about whether a
particular address is all-bits-zero or not -- and if you do care, then
you're doing some very system-specific stuff and you'd better know
exactly what you're doing.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #50

102 Replies

This discussion thread is closed

Replies have been disabled for this discussion.