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

[Olivier Galibert <galibert@pobox.com>]

On Tue, Jun 28, 2005 at 07:36:00PM +0100, Dave Korn wrote:
> ----Original Message----
> >From: Olivier Galibert
> >Sent: 28 June 2005 19:02
> 
> > 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",
> 
>   Please don't put words in my mouth.  That isn't remotely what I said, and
> if you are trying to paraphrase it, you have changed the meaning.  Undefined
> is not the same thing as implementation defined.

Sizeofs and encodings of the different type and behaviour on overflow
are implementation-defined, not undefined afaik.  In any case, if I
misunderstood you and you felt insulted, please accept my apologies.


>   Yep, but at that point, your definition starts to look uninteresting,
> because now it's starting to look like "We should be able to rely on signed
> ints wrapping in all circumstances, except those in which they don't."  A
> lot of this discussion has focussed on loop optimisations, but can you
> guarantee those are the *only* optimisations which really benefit from
> assuming signed ints don't wrap?  As far as I can see, it is reasonable for
> the C standard to say that all signed integer overflow is undefined because
> enumerating the circumstances in which it is or is not defined would be an
> unbounded and poorly-defined task.  A language feature that sometimes works
> and sometimes does not and there is no easy way to know whether it will or
> will not work in any given circumstances is *not* a useful feature, it's a
> dangerous ambiguity - worse than useless in a production environment.

You get it the wrong way around.  It's "We should be able to rely on
signed ints wrapping in all circumstances, except those in which we
don't care.".  In loop induction variables, usually people don't care.
In all the rest, they often do, especially in emulators and virtual
machines.  It's not an optimization when all you do is making programs
give the wrong result 0.1% faster.  Unless you want a repeat of the
strict-aliasing fiasco, only worse.


>   Well, I don't utterly _anything_ about either his position or yours.  C is
> not just a high level assembler, it has complex and abstract semantics
> imposed on that;

Yes.  But C is _also_ a high level assembler, and ignoring that is foolish.

  OG.