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

[Volker Kuhlmann]

On Tue 01 Nov 2011 02:12:17 NZDT +1300, Weddington, Eric wrote:

> > Eric, what changes are you thinking of for better lint-friendliness?
> 
> I was hoping you could tell me. ;-)

Back to me then ;-)

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. Crikey - what a mountain of syntax
errors. Let's fix the abberration (but still allow this to compile with
gcc) by including first

  #ifndef __GNUC__
  #define __attribute__(dumpit)
  #endif

At which point one is left with

  typedef int int8_t;
  typedef int int16_t;
  typedef int int32_t;

not knowing whether to groan, shake head, or just laugh.

So my suggestion (and attached patch) was to define these such that they
*ALSO* work when the __attribute__ part is cpp'ed away. Johann suggested
to look at INT_MAX to get the typedefs right.

For orientation, glibc and newlib don't have that problem, but also
don't use __QI__ etc. to define them.

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.

So far no-one has said whether this breaks anything.

But I don't want to spend any more time on this. I'll just fix my own
copy.

Greetings,

Volker

-- 
Volker Kuhlmann
http://volker.dnsalias.net/     Please do not CC list postings to me.