Re: [MiNT] gcc-3.0 patch available

[Johan Klockars <rand@cd.chalmers.se>]

> > > You're not. The -mshort option is not obsolete at all. I

Absolutely not!

> > > mainly use that flag for portability purpose with PURE C.
> > 
> > Yes, -mshort is present for compiling badly written C programs with GCC.
> 
> There are many ways you can write a program badly.

Yes, and this is not one of them.
Assuming 'int' is 32 bits is what's bad, since the standard only says that
it is at least as large as a short (which is at least 16 bit).

'int' is supposed to be the integer type that the machine handles nice
and fast, and for the majority of ST compatible machines that would be
a 16 bit type (which can often be handled twice as fast by a 68000).

That said, 'int' is pretty much universally 32 bit these days, and lots
of code assumes that it is...
(And yes, on all machines except my Ataris I assume int is 32 bit myself.)

> I dont think using a standard type that is part of the language can be
> considered bad in general.

Indeed.

> > I would suggest you to correct your code so compiling with or without
> > -mshort lead to the same results.
> > 
> The best thing to do is: when still only compiled with Pure C, replace ALL
> int by short. This is a safe operation and can be done fast.

It may not necessarily be quite that simple, since there is no guarantee
that the code produced will be as efficient. I had some problems like this
with Lattice C years ago where, IIRC, the output got a lot worse if I made
my 16 bit integers 'short' rather than leave them as 'int' and set the
compiler to use short integers.
Much of it was just Lattice being stupid, but for example function
parameters can not be passed as 'short'.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johank@omicron.se
                        | so hard to do |  WWW:      rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)