[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug(s) in 2.5.19 skel.c
From: |
Hans-Bernhard Broeker |
Subject: |
Re: bug(s) in 2.5.19 skel.c |
Date: |
Wed, 18 Sep 2002 12:47:41 +0200 (MET DST) |
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.
- Re: bug(s) in 2.5.19 skel.c, (continued)
- Re: bug(s) in 2.5.19 skel.c, Bruce Lilly, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Bruce Lilly, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Hans-Bernhard Broeker, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Bruce Lilly, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Hans-Bernhard Broeker, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c, Bruce Lilly, 2002/09/17
- Re: bug(s) in 2.5.19 skel.c,
Hans-Bernhard Broeker <=