THIS ARTICLES IS CROSSPOSTED TO comp.std.c.

In article <3jf5qs$8ua@bcarh8ab.bnr.ca>, Brian White <bcwhite@bnr.ca> wrote:
>In article <3j9di1$p2b@hustle.rahul.net>,
>Ronald F. Guilmette <rfg@rahul.net> wrote:
[...]
>>>... You can always compare the value of a pointer even if it
>>>doesn't point to anything...
>>
>>This is not true in standard C, and I also hope (for the sake of the imple-
>>mentors) that it will be not true in standard C++.
>
>I don't understand what you mean.  There is absolutely no checking in C or
>C++ on pointer ranges.  You can always compare the value of a pointer (not
>necessarily the value of what it _points_ to).
>
>eg: void* something;
> void* somethingelse;
> if (something != somethingelse) exit(1);

I believe you are wrong.  Imagine a machine where registers P0 and P1
are used when manipulating or comparing all pointer values.  Imagine
that a table of valid value ranges for those two registers is kept
somewhere, and that the machine checks that table every time a value
is loaded into P0 or P1.  The machine triggers a hardware exception
whenever an instruction attempts to store an invalid value in P0 or P1
(such as 0xFFFFFFF, which the compiler helpfully puts in all
unitialized pointers variables).

This isn't terribly far-fetched.  I believe CenterLine's ObjectCenter
debugger checks whether a pointer points into freed memory and gives
an error message, even when the program just compares that pointer
value against NULL.

Can someone confirm that ANSI/ISO C allows implementations like this?

>You'll get warnings from the compiler about using an uninitialized variable,
>but it will still compile and execute.  If this isn't comparing the value
>of a pointer that doesn't point to anything, I don't know what is.

Looking at what a C or C++ compiler *does* is very often a poor way of
determining what Standard C or C++ allows.  The compiler may simply be
wrong, or the program may be resulting in "undefined behavior",
meaning the compiler can do anything it wants (including do what the
programmer hopes it does).

Jamshid Afshar
jamshid@ses.com