signed is undefined and has been since 1992 (in GCC)
Olivier Galibert
galibert@pobox.com
Tue Jun 28 18:02:00 GMT 2005
On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote:
> It certainly wasn't meant to be. It was meant to be a dispassionate
> description of the state of facts. Software that violates the C standard
> just *is* "buggy" or "incorrect", and your personal pride has absolutely
> nothing to do with it.
Then your definition of "incorrect" is uninteresting. Per your
definition, "use of implementation-defined behaviour is incorrect",
essentially no non-trivial program is correct. Including gcc for a
start, which can't be correct, ever.
> If you re-read what *you* originally said, you made it look like you were
> talking in abstract terms about software-in-general,
I said "A very large number of C and C++ programs". That includes
kernels, gnome, kde, lots of things. Or if you want programs I
work(ed) on, xemacs and mame.
> and that's certainly
> what I was referring to when I replied; it's unreasonable of you to point at
> that very generalised sentence and suddenly say "I was talking about my own
> code, even though I hid the fact, and so you've insulted me by disparaging
> it".
You disparaged probably around 99% of a typical linux distribution.
Find one non-trivial program that doesn't assume that int is 32 bits.
Find one of *your* programs that doesn't.
> No number of correct assumptions about the sizes of various types or the
> representation of NULL pointers will validate the incorrect assumption that
> signed integer arithmetic could be made to wrap without obliging the
> compiler to emit lousy code and miss an awful lot of loop-optimisation
> opportunities.
Sure, and you'll notice I always special-cased the loop induction
variables. Maybe you should reread what I was replying to:
On Tue, Jun 28, 2005 at 08:57:20AM -0400, Robert Dewar wrote:
> But the whole idea of hardware semantics is bogus, since you are
> assuming some connection between C and the hardware which does not
> exist. C is not an assembly language.
That is what I utterly disagree with.
OG.
More information about the Gcc
mailing list