Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()

[Joerg Wunsch]

As Volker Kuhlmann wrote:

> I had already posted my solution. To recap, the problem is parsing
> 
>   typedef int int8_t __attribute__((__mode__(__QI__)));
>   typedef int int16_t __attribute__((__mode__ (__HI__)));
>   typedef int int32_t __attribute__((__mode__ (__SI__)));
> 
> with any standards-compliant parser.

And we already made it clear that we won't change *actual code* that
has been proven to work well for years, just for the sake of
satisfying whatever analysis tool being used.  What's next?  Are you
going to tell us to not use inline assembly statements, because they
are non-standard, and your analyser doesn't grok them?  Are you going
to tell us that __extension__ is evil and must be avoided?

This is a *system* library, and it is meant for just one compiler
(AVR-GCC), so we completely reserve the right to implement it in the
most efficient way we see fit GCC can handle.

However, what we are going to accept is patches that make the library
more "lint friendly".  For that, everything has to be wrapped in
#ifdef LINT (or #ifdef lint - I wouldn't care, but users should agree
on one of them), so preprocessing it without "LINT" being defined
yields the same code as before.

> I am not objecting to using the quantum mechanism to define the int
> types for gcc, I am objecting to the nonsense in front of that.

With the wording you are choosing, you won't convince anyone.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

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