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

[Theodore A. Roth]

On Mon, 11 Nov 2002, Joerg Wunsch wrote:

:) As Theodore A. Roth wrote:
:)
:) > :) Of course, <inttypes.h> needs my suggested fix applied first.  Any
:) > :) comments about that one?
:) >
:) > I think this should be done, but I'm not too excited about your patch
:) > (http://mail.gnu.org/pipermail/avr-libc-dev/2002-November/000492.html)
:) > dropping uint32_t.
:)
:) Well, then you need to complain about avr-gcc. ;-)  It's very simple:
:) the compiler simply doesn't provide and 32-bit integer type in
:) -mint8 mode.  You can easily verify this by using avr-gcc -E -dD.

Can't really argue that. ;-) If avr-gcc can't produce a 32 value in -mint8
mode, that's the problem then. I don't see a way around it since you only
have so many type available. I guess when using -mint8 you lose one of the
available types since int becomes an equivalent to char.

So to summarize:

Normal avr-gcc:

  char      -> 8 bit
  int       -> 16 bit
  long      -> 32 bit
  long long -> 64 bit

-mint8 mode:

  int <-> char -> 8 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.

:)
:) > Since this is a C99 standard file, what does the standard say needs to be
:) > in it? (I need to find a link to the standard... got something "ISO/IEC
:) > 8999:1999 (E)") Looks like we should really be doing all of this in
:) > stdint.h to conform to the standard.
:)
:) -mint8 is in violation of the standard anyway, int needs to cover at
:) least the range of -32767 to 32767.

So if avr-libc is a subset of the standard, why should we support -mint8?
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.

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

Ted Roth