avr-gcc-list
[Top][All Lists]
Advanced

[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: David Brown
Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect
Date: Wed, 11 Jan 2012 09:14:22 +0100
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0

On 11/01/2012 08:21, Joerg Wunsch wrote:
"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.


I disagree a little here. You are right on principle, and especially regarding things like int24_t that has little chance of matching anything standard in C.

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?

It's the best of both worlds. The __mode__ makes sure that it is exactly the correct width. The "unsigned long int" makes sense to readers, and to external tools.

Obviously the external tool needs to know that on the avr, a "long" is 32-bit - but it needs to know that anyway in order to work with user code. 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.


mvh.,

David



reply via email to

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