Re: bug(s) in 2.5.19 skel.c

[Hans-Bernhard Broeker]

On Mon, 16 Sep 2002, Bruce Lilly wrote:

> There is not even a theoretical problem with calloc or
> memset there, as ANSI/ISO C section 6.2.2.3 clearly states
> that a null pointer has value 0.

Wrong.  There definitely is a problem, and particularly with pointers.  
Calling memset() or calloc() creates "all bytes zero".  Which may seem to
be equivalent to "value zero" for the NULL pointer --- but it isn't,
because there is no fixed predefined mapping between pointers and
integers, including the integer zero. To isolate the point: after

        whatever * pointer;
        memset(&pointer, 0, sizeof(pointer))

it is *not* reliably guaranteed that

        pointer == 0;
or      pointer == NULL;

holds.  Actually, both of these comparisons cause undefined behaviour.
Read the C FAQ if you don't trust my words, or at least re-check the
extract I quoted from it.

> Regarding integral types, the requirements of ANSI/ISO C section
> 6.1.2.5 means that for all practical purposes a zero valued integer of
> any size will be all zero bits,

There's no such section in the C9x draft I have here.  Could you give the
title of that section so I can look it up?

Anyway.  As far as I'm aware, this only holds for the *value* bits.  The
problem is that C9x explicitly allows additional memory bits to exist,
which are part of the memory usage, but not used for holding the value.
I.e. it's not necessarily true that

  pow(2,sizeof(integer_type)*CHAR_BIT) == cardinality(integer_type)

for any integer_type other than unsigned char. IIRC, C89 neglected to
specify anything about such representation details.  C9x now explicitly
says that representations may have padding bits, and that certain contents
of these bits could well cause the CPU to trap if you access the value by
any means other than as a collection of bytes.  It'd be pretty silly of a
C toolchain maker to make all-bits-zero a trap representation, but then,
the CPU makers may not have left any other choice.

> and efficient implementation of bit fields (6.5.2.1) virtually
> guarantees it.

The C standard doesn't control hardware architectures.  So there's no
reason at all to assume that bit fields *can* be implemented efficiently
in the first place, on a given platform.

-- 
Hans-Bernhard Broeker (address@hidden)
Even if all the snow were burnt, ashes would remain.