Re: [avr-libc-dev] inttypes.h cleanup for -mint8

[Joerg Wunsch]

As E. Weddington wrote:

> I just wish that there was a switch that causes gcc to not
> automatically promote to int when an expression's arguments are both
> unsigned char.

That would seem useful, yes.

As Marek Michalkiewicz wrote:

> I remember that long long ago Denis said something about removing
> support for -mint8 completely - perhaps it's still there only due to
> lack of time to remove it ;-)

I'd vote for not removing it.  In particular in the world of small
microcontrollers (and the ATtiny line seems to be continued), there's
some justification for it.

> If the main reason for using -mint8 is better code from "switch"
> statements (no conversion to a 16-bit int before comparing), I think
> it is better to rewrite such code as a series of if/else statements.

That's what you get with -mno-tablejump, anyways.  But there are more
things where an `int' is implied:

. bitwise operators
. enum datatypes
. probably more i just can't remember right now ;-)

Sure, you can invent separate switches for each of them, but in
effect, it's not so much different from having -mint8.

As Theodore A. Roth wrote:

> So to summarize:
> 
> Normal avr-gcc:
> 
>   char      -> 8 bit
>   int       -> 16 bit
    short     -> 16 bit
>   long      -> 32 bit
>   long long -> 64 bit
> 
> -mint8 mode:
> 
>   int <-> char -> 8 bit
    short        -> 16 bit
>   long         -> 16 bit
>   long long    -> 64 bit

> Hmm, seems to me that long long when using -mint8 would be better
> defined as 32 bits and forego the the 64 bit value. I have seen
> systems lacking a 64 bit type, but never lacking a 32 bit type.

Yep, i also thought so.  Instead of dropping -mint8 completely from
avr-gcc, my vote also goes for making long long a 32-bit type then.

> So if avr-libc is a subset of the standard, why should we support
> -mint8?

I don't want to `support' it, in the closer sense of the word.

But as it is now, the non-support for -mint8 in avr-libc is probably
80 % due to sloppyness, careless use of `char', `short', `int' etc.
where an explicit `uint8_t', `uint16_t' etc. would have stated the
real intent of the programmer.  In all those cases, where it basically
doesn't cost us any much work, or twist of brain :) to keep it
compatible with -mint8, i think we can do it provided someone really
volunteers to keep an eye on this.  <inttypes.h> is just a starting
point (it's quite obvious that it simply doesn't care about the -mint8
case by now), other things might follow.  Nils Kristian has shown us a
few things that are easy to fix.  If he continues like this, he can
easily become a candidate for said volunteer :), at least he's already
got a motivation.

So not just `support' it, but remain compatible with -mint8 where it's
possible without compromises, and then document what is just
incompatible so someone who really considers using -mint8 has a
decision base.

> I'm not totally against it, I just want strong arguments for it since it
> will mean more work and complicate the code with #ifdef's.

Most of the time, no #ifdefs are needed.  If you include <inttypes.h>,
and use an explicit-sized integer type instead of silently assuming a
particular size of the type, the only #ifdef will remain in
<inttypes.h>.

> BTW: -mint8 also breaks avr-gdb serverely. So debugging a -mint8 project
> becomes impossible with gdb.

Just document it, and you're done. :)

(I assume the same will be true for AVRstudio?)
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/