Re: NULL with representation other then all bits 0

Christian Bau <christian.bau@xxxxxxxxxxxxxxxxxxxx> writes:
> In article <lnacdde01m.fsf@xxxxxxxxxxxxxxx>,
> Keith Thompson <kst-u@xxxxxxx> wrote:
>> Christian Bau <christian.bau@xxxxxxxxxxxxxxxxxxxx> writes:
>> > In article <lnpsmau858.fsf@xxxxxxxxxxxxxxx>,
>> > Keith Thompson <kst-u@xxxxxxx> wrote:
>> [...]
>> >> For example:
>> >>
>> >> char *null_ptr = 0; /* guaranteed to be a null pointer value */
>> >> int zero = 0;
>> >> char *maybe_null = (char*)zero;
>> >> /* may or may not be a null pointer */
>> >>
>> >> The requirements for null pointer constants apply only to compile-time
>> >> constructs.
>> >
>> > I believe this has been added as a requirement in C99.
>>
>> What has? Do you mean that maybe_null in the example is required to
>> be a null pointer under C99?
>>
>> I don't believe that's correct. In particular, I don't believe the
>> requirements have changed significantly between C90 and C99. (Of
>> course I've been wrong before.) Can you provide chapter and verse?
>
> From the n1124 draft:
>
> 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 anyobject or function.
>
> 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.3.2.3.3 only talks about conversions, it doesn't talk about when
> conversions happen (which has a special case for null pointer
> constants). It says what the result of a conversion from an integer type
> to a pointer type is in one special case. Note that we have here a full
> conversion, and not a substitution.
>
> I assume that the result of a conversion can only depend on the value
> and the type of the thing that is converted, which implies that anything
> that has a type and a value that could be the type and value of a null
> pointer constant _must_ be converted to a null pointer. (I don't think
> it is possible to have a null pointer constant of type char or short, so
> converting a char or short of value 0 to pointer type might not be
> guaranteed to produce a null pointer with this reasoning).
>
> As an example, in
>
> char* p = (char *) 0;
>
> the special rules for null pointer constants are not invoked;
>
> char* p = (char *) 1;
>
> would be just as legal; it is just a conversion from int to char*. The C
> Standard defines the result in the very strict case we have here, that a
> null pointer constant is converted, but the result of a conversion
> cannot depend on this fact. Zeroes that are not null pointer constants
> are not mentioned in the rule, but they cannot be converted differently.
>
> The result is implementation defined; an implementation would not be
> free to define different results for
>
> (char *) 1
> (char *) (1 + 0)
> (char *) (int) (1.73f)
>
> because they all convert the same value. Neither can it define different
> results for different zeroes.

To summarize your argument:

(1) The standard guarantees that an integer constant expression with
the value 0, when converted to a pointer type, yields a null
pointer value.

(2) The result of a conversion depends only on the value and type of
the operand.

(3) Therefore, the integer value 0, when converted to a pointer type,
yields a null pointer value.

I'm not convinced that (2) is necessarily required. (It's going to be
true in the majority of real-world implementations, on which null
pointers are represented as all-bits-zero, but those aren't the cases
we're worried about.)

The conversion of an integer constant expression is a special case.
If it had been intended for the conversion of a non-constant zero to
yield a null pointer, the standard could have said so, and it would
have been simpler than the current wording.

In particular, I believe the following could be a conforming
implementation:

Pointers are 32 bits. A null pointer is represented uniquely as
0xffffffff. A pointer with the representation 0x00000000 is not a
null pointer. Conversion of an integer constant expression with the
value zero to a pointer type yields a null pointer value (as required
by the standard). Conversion of a non-constant integer expression to
a pointer type yields a pointer value with the same representation as
the integer (possibly zero-extended or truncated).

For example:

void *null_ptr = 0; /* obviously a null pointer */
void *null_ptr2 = (void*)0xffffffff; /* a null pointer */
int zero = 0;
void *zero_ptr = (void*)zero; /* not a null pointer */

null_ptr2's value is a null pointer, but (void*)0xffffffff is not a
null pointer constant.

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.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <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.
.

Relevant Pages

  • Re: 0, NULL and variadic functions
    ... and a null pointer constant at the same time (with or without ... null pointer constant, without having pointer type. ... The integer constant 0 is specifically of type int; ... the conversion is performed *by the assignment*. ...
    (comp.lang.c)
  • Re: NULL with representation other then all bits 0
    ... >> I believe this has been added as a requirement in C99. ... expression cast to type void *, is called a null pointer constant. ... It says what the result of a conversion from an integer type ...
    (comp.lang.c)
  • Re: ptr conversions and values
    ... >> each pointer pointed to a byte, ... Without that conversion, a pointer that points to an N-byte ... pointers to incomplete array types must indicate the start of the array ... >> It's all right, mostly equivalent with the previous one, representation ...
    (comp.std.c)
  • Re: does a program work in all cases?
    ... A null pointer constant has whatever type it has as an expression. ... long int, etc.), or "such an expression cast to type void*", which has ... the result of the conversion is of type double*. ...
    (comp.lang.c)
  • Re: typecast internals
    ... (snip of description of floating point formats) ... >>that the value is of the appropriate pointer type, ... > much of a conversion operation as arithmetic-type casts. ...
    (comp.lang.c)