[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 08:21:35 +0100 (MET)

"Paul McClean" <address@hidden> wrote:

> Can anyone explain why the GCC instructions are used in place of the
> typical definition?

Because the mode names are GCC's equivalent for specifying a
particular number of bits.

> Could it be expressed as:
> unsigned long __attribute__ ((__mode__ (__SI__))) 
> with both the standard C part and the GCC part indicating the same size?

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
long' datatype could as well have 64 bits, still conforming to the
standard.  Likewise, an `unsigned int' on many GCC targets is 32 bits
long, so why does your tool assume it were 16 bits?

Moreover, how would your tool handle Johann's recent GCC addition of a
24-bit integer type?  This one can only be expressed by relying on the
definition of __int24_t (or __uint24_t) providing the necessary magic
to tell this to the compiler.

> (This would keep my static analysis tool happy).

Your tool should IMHO treat system headers (at least those that are
specified in the C standard) as `opaque', and trust the
standard-mandated definitions to perform exactly what they are
required to do, regardless of *how* they are defined.

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]