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. ;-) _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
