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

[David Brown]

On 01/11/2011 11:28, Joerg Wunsch wrote:
> 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.

While I agree with your principle here, I think there is good reason for 
changing the typedefs in this case - and nothing to lose.  People use 
different tools with their code, such as static error checkers, 
documentation generators, and "smart" editors like Eclipse.  They also 
sometimes read the files.

The use of __attribute__((__mode__)) as the sole way to define sizes 
seems to me to be gratuitously non-standard.  I am all in favour of 
using non-standard constructs or extensions when they are a help - 
making source code clearer, shorter or more readable, letting the 
compiler generate smaller or faster object code, or simply implementing 
features that can't be expressed in standard C.  But this is not such a 
case.

I appreciate "don't change something that works" as a good reason for 
leaving the typedefs as they are.  But you have to weigh that against 
changing it to something clearer and standard, easier to read, easier to 
maintain (not that there is likely to be many changes), and easier to 
use with other tools.

It is even more ironic that there are already standard definitions in 
stdint.h precisely to support tools other than avr-gcc, namely doxygen.


I also wonder if there are differences in the way gcc treats "mode" 
attribute definitions from standard definitions.  In particular, in C a 
"unsigned char" is /not/ identical to an "8-bit unsigned int".  The 
"unsigned char" has different aliasing properties than an "unsigned int" 
of any size.  Will code that relies on the these aliasing properties 
work correctly with "uint8_t" as defined in avr-libc?  And will it 
/always/ work correctly, with future versions of avr-gcc?

mvh.,

David


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