[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Volker Kuhlmann
Subject: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
Date: Sun, 30 Oct 2011 10:37:31 +0000
User-agent: Mozilla/5.0 (compatible; Konqueror/4.6; Linux) KHTML/4.6.0 (like Gecko) SUSE

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)

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

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:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]