[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

From: Joerg Wunsch
Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect
Date: Wed, 11 Jan 2012 18:53:17 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

As David Brown wrote:

> But where is the harm in having uint32_t typedef'ed as:
>       unsigned long int __attribute__ ((__mode__(__SI__)))
> Is there any hidden cost or disadvantage here that I (and others) are
> not aware of?

No, it could be done.  I just don't think it's a cool idea to work
around some tool's flaws by tweaking the library.  (OK, we already
did that for Doxygen. ;-)

> And I don't think the tool can assume that "uint32_t" is 32-bit, 
> just because the standard says that this type must be 32-bit if it 
> exists - people write code that doesn't conform to standards.  Tools 
> will, I believe, pick up on the size of uint32_t by tracing back to the 
> system header and reading it.

That's where we disagree.  I think if a particular type name is
mandated by the standard, the tool should rely on it being that way,

It could easily happen the entire declaration is completely hidden
(rather than being exposed as in avr-libc's header).  For example, GCC
4.5.1 ships with its own stdint header file which has constructs like:

#ifdef __INT8_TYPE__
typedef __INT8_TYPE__ int8_t;

In that case, the definition of the macro __INT8_TYPE__ cannot be seen
by that tool at all, still, int8_t will be defined at compile-time.

If a user is so stupid to define uint8_t to be a 32-bit type, the tool
won't save their ass either. :-)

As Georg-Johann Lay wrote:

> > The standard C does not make *any* claim about the actual number of
> > bits in an `unsigned long' data type, it only specifies a *minimum*
> > number of bits (indirectly, by telling a minimal magnitude value for
> > LONG_MIN, LONG_MAX, and ULONG_MIN, respectively).  Thus, an `unsigned
> The C standard says it is implementation defined.

... but requires minimum values, effectively mandating a minimal
number of bits to implement it.

> The implementation (AVR backend of GCC) say: long is 32 bits or 16 bits 
> if -mint8 is on.

Well, -mint8 violates the standard anyway, and I doubt that tool would
stand the slightest chance to cope with -mint8 code.

> As avr-libc is only intended to work together with GCC, avr-libc could 
> use built-in macros:
> typedef __INT32_TYPE__ int32_t;

I've got the impression these macros are a recent addition.  Would
that also work e.g. on GCC 3.4?  I know there are still users of
avr-libc working with such old compilers (since the compiler gets a
better code density for them).

> As fas as I know the only reason why avr-libc used mode attribute is to 
> factor out impact of -mint8, ...

No, our previous definitions were -mint8 clean, AFAICT.  It just
looked more elegant to use GCC's mode attributes to ensure certain bit
widths, so when someone was proposing that change, we accepted it.
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]