Re: bug(s) in 2.5.19 skel.c

[Bruce Lilly]

Hans-Bernhard Broeker wrote:
> On Tue, 17 Sep 2002, Bruce Lilly wrote:

> > > Exactly.  And it specifically does *not* deal with any other type.
> > > Since an integer is not just a collection of bytes
> >
> > In your last message, you said that it was legal and valid to
> > treat it as a collection of bytes.
>
>
> I don't remember having said anything like that, sorry.  Quotation,
> please?

"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."
                     ^^^^^^^^^^^^^^^^^^^^^^^^

> 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".

> > The assignment of const struct foo default_foo to (not const) struct
> > foo *x will almost certainly generate a diagnostic about qualifier
> > mismatch (const).
>
>
> Such a warning should be considered insane and ignored, IMHO.  But yes, I
> know it happens. If the compiler author who put in that warning thinks I
> shouldn't assign a const value to a non-const variable, then what on earth
> does he think the "const" attribute is supposed to be useful for?

The warning is valid, because with your suggested code,
it is possible to:

x = (struct foo *)(&default_foo);
x->bar = (struct foo *)x;

or some such thing, which causes assignment into the
supposedly const default_foo.  If there is no hardware
protection against that, and the default_foo storage is
shared (as in a shared object, which is a principal use
of reentrant code), one has the makings of a trojan
horse.


> The issue is, what do you care for more: avoiding silly warnings from
> silly compilers, or avoiding known-unportable code that might just solidly
> break tomorrow, as you try a new compiler option or hardware platform you
> never used before?

It's the non-portable and unsafe code that generates
the warnings (from gcc, e.g.).

> Use memcpy(), then.

That doesn't help if default_foo isn't initialized fully.
It also doesn;t prevent default_foo from being modified
via a non-const pointer.

> 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.