Re: signed is undefined and has been since 1992 (in GCC)

[Olivier Galibert <galibert@pobox.com>]

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.