Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > NULL with representation other then all bits 0

Reply
Thread Tools

NULL with representation other then all bits 0

 
 
Keith Thompson
Guest
Posts: n/a
 
      01-31-2006
http://www.velocityreviews.com/forums/(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:
[snip]
> Yes, for any given object type, two null pointers are guaranteed
> to compare equal, even if they do not have the same internal
> representation.
>
> This is not -necessarily- as bad as the code that compares pointers
> needing to iterate through all the different null pointer representations.
> The compiler knows that pointer types at the time of the
> comparison, so if some of the null pointer representations are not
> possible for a given type, then the compiler would not need to
> test that possibility. In particular, if there happens to be
> exactly one null pointer representation per type (but that different
> types might have different null pointer representations) then only
> one test would need to be made.
>
> This comparison process is potentially further simplified by the
> fact that one cannot convert pointers directly between
> incompatible types without going through void* [if I recall correctly].
> The conversion into void* could produce a "canonical" null pointer
> and the conversion of the "canonical" null pointer into a different
> pointer type would choose one of the null pointer representations
> valid for that type; in this way, one only has to deal with the
> null pointer representations valid within the type. One thing to
> watch out for here is that when a pointer is converted to void* and
> converted back to the same type, the original pointer and the
> double-converted one must compare equal -- but in the end this just
> comes down to potentially needing to be able to compare multiple null
> pointer representations for a single type.

[snip]

No, you recall incorrectly. C99 6.3.2.3p7:

A pointer to an object or incomplete type may be converted to a
pointer to a different object or incomplete type.

(followed by caveats about undefined behavior for incorrect
alignment).

But a compiler could certainly implement pointer-to-pointer conversion
by converting to void* and then to the other type.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      01-31-2006
Gordon Burditt wrote:
>

.... snip ...
>>
>> Gordon, *please* don't snip attribution lines. In following a
>> discussion, it's important to know who said what.

>
> It is more important not to misattribute someone's words to
> someone else.
>
>> Your headers indicate that you're using the "trn" newsreader;
>> I'm reasonably sure it does attributions correctly.

>
> If I don't snip attributions, I get complaints of the form "I didn't
> say that" from at least two people complaining that I attributed
> the SAME text to each of them. On *EVERY* *SINGLE* *POST*. Even
> if there was only one attribution left in. And some of them threaten
> lawsuits. If attributions are supposed to indicate who said what,
> it's not working, as clearly not everyone interprets them the same
> way.
>
> attribution -> misattribution
>
> Note that it's completely irrelevant as to whether *I* can interpret
> attributions correctly. I think I can, but I doubt anyone else
> cares. And I think what was said is much more important than who
> said it, at least most of the time.


Come on now. All it takes is the ability to count up to 3 or 4
'>'s at the head of each line you quote. Find the max, and remove
attribution lines which have that many or more '>'s. Also yell at
idiots who use non-standard quote markers. I am fairly sure you
are capable of that.

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943


 
Reply With Quote
 
 
 
 
Christian Bau
Guest
Posts: n/a
 
      02-01-2006
In article <(E-Mail Removed)>,
Keith Thompson <(E-Mail Removed)> wrote:

> I admit that having (void*)0 and (void*)zero yield different values is
> counterintuitive, but so is the whole idea of C's null pointer
> constants IMHO. C's definition of a null pointer constant is so
> narrow that I think it has to allow for this possibility.


Null pointer constants are not very counter-intuitive really. All that
the C Standard says is that in some cases, when you write 0 in a
program, you actually get for example (char *) 0. There are similar
situations: If a is an array, then in many situations where you write a,
you actually get &a[0]. Or if you declare a function parameter as an
array, like in int f (int a[10]); you actually get a pointer like int f
(int* a).
 
Reply With Quote
 
Jordan Abel
Guest
Posts: n/a
 
      02-01-2006
On 2006-01-31, Flash Gordon <(E-Mail Removed)> wrote:
>> But at runtime, you'd have to have all null pointer values compare
>> equal to all other null pointer values, right? So if on a particular
>> implementation, a segment number of 0 indicates a null pointer,
>> regardless of the offset, protection ring, or assorted other bits
>> making up a pointer, the code that compares pointers would have to
>> deal with this?

>
> Yes, or ensure that valid C code only generates one form of null
> pointer. So it is exactly the same as the situation where you can have
> both +ve and -ve zeros, either only one type must be generated or they
> must compare equal.


Another example is on some x86 implementations, where pointer comparison
in general is on the offset only, and offset bits of 0 make a null
pointer. Of course, this also provides a reason that casting a null
pointer to an integer type doesn't necessarily result in 0. 3000:0000
cast to long would become 0x30000000L, not 0L
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-01-2006
Christian Bau <(E-Mail Removed)> writes:
> In article <(E-Mail Removed)>,
> Keith Thompson <(E-Mail Removed)> wrote:
>> I admit that having (void*)0 and (void*)zero yield different values is
>> counterintuitive, but so is the whole idea of C's null pointer
>> constants IMHO. C's definition of a null pointer constant is so
>> narrow that I think it has to allow for this possibility.

>
> Null pointer constants are not very counter-intuitive really. All that
> the C Standard says is that in some cases, when you write 0 in a
> program, you actually get for example (char *) 0. There are similar
> situations: If a is an array, then in many situations where you write a,
> you actually get &a[0]. Or if you declare a function parameter as an
> array, like in int f (int a[10]); you actually get a pointer like int f
> (int* a).


Whether something is counterintuitive or not is bound to be a matter
of opinion. I won't say you're wrong, but I will say that my opinion
is unchanged. If it it were only the integer literal 0 that's
overloaded as a null pointer constant, it wouldn't be so bad, but the
standard requires 0, '\0', 0UL, ('/'/'/'-'/'/'/'), and (3/4) to be
treated as null pointer constants as well (probably so compilers can
perform constant-folding but don't have to remember they've done it),
but *doesn't* require a non-constant integer value of 0 to yield a
null pointer value when converted (at least, I don't *think* it does;
there's still some debate on that point). It leads too many people to
assume that a null pointer *value* is represented as all-bits-zero
(which isn't an entirely unreasonable assumption given that
integer-to-pointer conversion usually just reinterprets the bits), or
at least that pointers are really just integers.

Just look at the time we spend discussing it here, and how much room
it takes up in the FAQ. And think how much of this we could have
avoided if the original C had added a keyword "nil" and made it the
*only* valid null pointer constant.

If you find all that stuff intuitive, you have better (or more C-like)
intuition than I do.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
all-bits-zero pointer-to-object representation Ersek, Laszlo C Programming 20 04-30-2010 11:32 AM
Can "all bits zero" be a trap representation for integral types? Army1987 C Programming 6 07-07-2007 12:01 PM
Help. SessionID is x then y then x then y BodiKlamph@gmail.com ASP General 0 09-03-2005 03:02 PM
Read all of this to understand how it works. then check around on otherRead all of this to understand how it works. then check around on other thelisa martin Computer Support 2 08-18-2005 06:40 AM
8-Bits vs 12 or 16 bits/pixel; When does more than 8 bits count ? Al Dykes Digital Photography 3 12-29-2003 07:08 PM



Advertisments