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: avr-gcc-list-bounces+p.mcclean=kelvatek....@nongnu.org [mailto:avr-gcc-list-bounces+p.mcclean=kelvatek....@nongnu.org] On Behalf Of Joerg Wunsch Sent: 11 January 2012 17:53 To: avr-gcc-list@nongnu.org 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 AVR-GCC-list@nongnu.org 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&from=p.mccl...@kelvatek.com _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
