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

[David Brown]

On 01/11/2011 13:10, Georg-Johann Lay wrote:
> David Brown a écrit:
>
> > 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.
>
> -mint8 is non-standard C

Correct.

> > 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?
>
> Aliasing is a good point.

It is subtle issues like this that worry me - they are hard to spot, 
hard to test, and /very/ difficult to debug if they affect users code. 
I am not saying that the use of "mode" gets aliasing wrong - just that 
we should be very sure that it gets it right if the typedefs are not 
standardised.

gcc gets cleverer every release - but that also makes it more and more 
important for users to understand the nuances of the C standards, and 
for the tools to work perfectly according to those standards.  Otherwise 
the compiler and the user and going to be making different assumptions, 
and things break in mysterious ways.

The other possible issue that springs to mind is debuggers - will 
debuggers always be happy with non-standard definitions of the types?

> But as the moment discussing -mint8 features is void because that
> feature is broken some time now (PR46261).
>
> Johann

Could -mint8 be removed entirely?  It would simplify some library code 
(such as stdint.h), and would no doubt simplify things in the compiler. 
 I know gcc always likes to have a "deprecation" period before removing 
features, but doesn't "hasn't worked for some time".

As far as I can tell, the main reason for not removing -mint8 is that 
people used it to get the smallest possible code, since there were a 
number of "missed optimisations" due to 8-bit to 16-bit integer 
promotion.  But many of these have been fixed, or at least greatly 
improved, in gcc 4.7 (thanks especially to Johann, I believe).

mvh.,

David