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

[Olivier Galibert <galibert@pobox.com>]

On Tue, Jun 28, 2005 at 10:50:39AM -0700, Joe Buck wrote:
> On Tue, Jun 28, 2005 at 07:17:52PM +0200, Olivier Galibert wrote:
> > On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
> > > This is childish and insulting.
> > 
> > Calling a large part of the programs out there, including a non
> > negligible subpart of what I personally write either "blatantly buggy"
> > or "subtly-incorrect" is somewhat childish and insulting.
> 
> I agree, partly, with Olivier.  However, let's not insult each other;
> we need to recognize that GCC developers have to worry about embedded
> systems, where some of the assumptions Olivier makes do not hold.

Oh yes.  But you have to be careful not to break them for the
non-embedded world, and in any case I was only answering to the
affirmation that "C the language is disconnected from the hardware".

Incidentally, gcc itself makes most of these assumptions in its own
code.  I kinda doubt you can run it on a dsp or a machine with 16-bits
ints.  Which is different than generating code for them.


> However, I am careful to document them, and disagree with a couple
> (particularly assuming things about unaligned access; even when the
> architecture permits it, there's a substantial speed penalty).

Sure, and I tend to avoid them too, especially since I still run code
on sgis and alphas.  Still, they're often considered slow but not
crashing in lots of programs out there.

> Also, some of Olivier's assumptions could lead to less maintainable
> code; sloppy typing can hide errors, even for assumptions that are
> safe with all ILP32 and LP64 machines with IEEE FP.

The pointer/long interchangeability, thankfully, appears less often.
I see it raise its ugly head essentially in cases of printing (%p is
recent), pointer difference (which fits in a long but not an int),
virtual machines where storage is tightly controlled (lisp engines in
particular), and more often when you want to pass a value through a
library-opaque void * (thread starts, callbacks) but you do not want
to have structure lifetime issues.  In these cases you know you can
pass up to a long unscathed.


> It would be best to say that the assumptions are non-portable, too
> non-portable to be used in code contributed to GCC.

Some are already there and won't go, the most obvious one is that int
is more than 16 bits.  There are also some:
    INDEX_EDGE (edge_list, i)->aux = (void *) (size_t) i;

which is I guess one of your cases of sloppy typing.  I'm sure we can
find a number of assumptions you wouldn't like on the boehm collector
too, simply because code so close to the memory management needs them
badly.

  OG.