Re: bug(s) in 2.5.19 skel.c

[Hans-Bernhard Broeker]

Me:
> >>>Exactly.  And it specifically does *not* deal with any other type.
> >>>Since an integer is not just a collection of bytes

Note that I said "is not _just_ a collection of bytes" above, i.e. an
int has more to it than that collection of bytes.  

Bruce:
> >>In your last message, you said that it was legal and valid to
> >>treat it as a collection of bytes.

Bruce, Quoting me:
> "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."
>                       ^^^^^^^^^^^^^^^^^^^^^^^^

Thanks for the reference.  I see now how this misunderstanding arose. This
sentence indeed wasn't worded nitpicky enough to be watertight.

You can't access the _value_ by treating it as a collection of bytes. You
can only access the _memory_ used by that variable as a collection of
bytes.  In this sense, yes, it is legal to treat the integer as a
collection of bytes.  But once you've written to it this way, you may
*not* read it as an integer any more.  You have to write a new integer
into it, first.  So the integer value effectively ceases to exist the
moment you call memset() on it.

The core of the problem is this: nobody but the platform itself and its C
compiler really knows the relation between a collection of bytes and the C
datatype they represent (with the obvious exception of the C datatype
being a collection of bytes, itself).  Code that makes any assumptions
about this relationship causes undefined behaviour.

> > Which, of course, raises the age-old question: in case of conflict, what
> > is more sane and/or important: taking care of already broken platforms, or
> > avoiding to break the un-broken ones?
> 
> Traditional (K&R) platforms aren't "broken"; they implement a valid
> language called C.  Just because they don't support the latest bits of
> featuritis (hex floating point, anyone?) doesn't make them "broken".

Platforms that still have only K&R C today, 13 years after the ANSI C89
standard, *are* broken, by my book.  Where "broken" would mean: in
desperate need of maintenance.  The only viable excuse for still not
having a C89 compiler today is that the platform has been left completely
unmaintained for at least 10 years.  I tend to consider such a platform
dead.

If we never make the decision to finally drop support of K&R-only
compilers, we'll remain chained to the era of the dinosaurs for ever. That
strategy is, of course, the exact opposite of featuritis, and it's exactly
as silly as that.

[...]
> The warning is valid, because with your suggested code,
> it is possible to:
> 
> x = (struct foo *)(&default_foo);
> x->bar = (struct foo *)x;

Are you kidding me?  I did *not* suggest that code.  My suggestion was
        
        struct foo *x = malloc(sizeof *x);
        *x = default_foo;

Which is an entirely different ballgame.  I never said you should be
assigning pointers.  I was talking about struct assignment.  That pointer
assignment of yours should indeed generate a warning, because the code is
seriously wrong.

> > Use memcpy(), then.
> 
> That doesn't help if default_foo isn't initialized fully.

If it isn't (using my proposed initializer of just {0}), that's a compiler
bug.  Not something that doesn't happen, sadly, but still a bug.

> It also doesn;t prevent default_foo from being modified
> via a non-const pointer.

It does as long as at least some of the developers keep full compiler
warnings active on a regular basis, so they will catch the warnings about
dropping 'const' in pointer assignments or argument passing.

> > And if you really worry about the coherence that much, create a macro or
> > function that combines the malloc() and initialization, as in
> 
> calloc() does just that.

It would, if only its method of initialization was correct.

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