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

[Volker Kuhlmann]

Follow-up Comment #3, bug #34695 (project avr-libc):

The trivial way to deal with lint (its splint incantation or whichever other
one) is to use run lint with -DLINT and to use this in code:

#ifdef LINT
#define __attribute__(discard)
#endif

lint will for sure only grok standard C, which __attribute__ is not.

I don't know what parser eclipse uses but my feeling is it has its own.
Obviously it's able to ignore __attribute__, and it's entirely within its
right to ignore it altogether. eclipse supports any compiler, so why should it
learn about every proprietary extension?

The good reasons gcc uses the attribute-based information are irrelevant here,
fact is it does, and fact is avr-libc falls flat on its face with anything but
gcc.

Are there any drawbacks with declaring those types in a way that would still
work if __attribute__ was absent? Because if not, not doing so is just
stubborn but not helpful when there are advantages in doing so. Just because
you can put any standard int type in there (because gcc ignores it anyway)
doesn't mean you should.

I don't much care about -mint8, it seems well on its way to the scrap heap of
"seemed like a good idea at the time", so I'm in favour of fixing things for
the absence of -mint8 (or for both if -mint8 can be tested for in an #ifdef).


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?34695>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/