26/32bit Acorn C/C++ Tools and OSLib

[Kevin Bracey]

In message <A49BB348EDE2A245A500A4863D5E8B2B13379F at namn100a.sbs.be>
          TIMMERMANS ANDRE <Andre.Timmermans at sbs.be> wrote:

> > The only problem I saw so far (and then didn't continue to use the
> > 26/32bit tools) that is much more picky on function defintions without
> > return type, and using functions before they have been declared etc.  I
> > thought that I should have been able to get around it by using flags like
> > -pcc but that didn't help (caused other problems).  :-(
> > 
> If you are using the new tools, I think there is a -c90
> mode to revert to the old c90 standard instead of the c99 one.

That should deal with the removal of implicit int fine. You also lose "long
long", but if you're just need it during the build process, and the resulting
headers still work with C99, then no worries.

The compiler will still be a bit stricter in C90 mode - for example "int
fred[] = {};" is now rejected (and always should have been). If you think
it's rejecting anything it shouldn't, point it out.

> So far my main complain with c99 on my own projects is the warnings
> about implicit conversions of signed integers given as hex
> in the range [0x8000000,0xffffffff].

Of course, integers given as hex in the range 0x80000000,0xffffffff are
unsigned ints, because you can't fit numbers as large as that into a signed
int :) Such an assignment is implentatation-defined behaviour, but of course,
this implementation does actually do what you expect.

The compiler's existing checks for non-fitting numbers (which already covered
things like "char c = 0x100;") are now able to spot 32-bit overflow, because
the compiler is using 64-bit arithmetic internally. To shut it up, you should
tell it that you know what you're doing by explicitly casting it to int, as
Stewart pointed out. I don't think adding suffices to the number would help
anything.

-- 
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/