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

[Paul McClean]

Unfortunately the static analysis tool I am using isn't aware of
uint32_t, etc. Instead it requires to be told what are the sizes of the
standard types on the target and it will then check that there are no
dangerous casts, comparisons, etc. It works out what any typedefs are
based upon interpreting the headers itself, but doesn't understand the
special GCC syntax.

Paul

-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Joerg Wunsch
Sent: 11 January 2012 17:53
To: address@hidden
Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are
incorrect

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,
period.

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;
#endif

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. ;-)

_______________________________________________
AVR-GCC-list mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list

--
Asylia ExchangeDefender Message Security: Click below to verify authenticity
http://www.exchangedefender.com/verify.asp?id=q0BI04Tw027272&address@hidden