Fri 16 Nov 2012 06:54:53 PM UTC, comment #8:
This issue needs to be considered along with other stdint.h changes in bugs #36571, #35539.
|
Fri 01 Jun 2012 11:08:08 AM UTC, comment #7:
FYI, the attached files show avr-gcc's understanding of the C99 types with and without -mint8
You can use these defines as a blueprint for the stdin.h headers or use them directly (once a fix for http://gcc.gnu.org/PR46261 is upsteram).
The advantage of using the types direcly like in
#define int8_t _INT8_TYPE_
is that you don't need to bother with -mint8 on or off.
Moreover, the definitions will be in sync with the compiler's
implementation.
The disadvantage is that you get more closely tied to the compiler and scanner's like link might easy going with open coded defines.
(file #25969, file #25970)
|
Wed 28 Mar 2012 09:54:02 PM UTC, comment #6:
Let me add that the way AVR-Libc defines its stdint.h causes bit of "trouble" in avr-gcc, too:
GCC's C testsuite contains tests for stdint.h, but many of them fail if avr-gcc testsuite runs in the most common setup: with AVR-Libc as libc implementation.
Reason is that avr-gcc's understanding of types is different, for example "long int" for int32_t instead of int _attribute_((mode(SI))). See how _INT32_TYPE_ precompiles.
Thus, if AVR-Libc's stdint.h is changed, it's very much appreciated if the change is coordinated with avr-gcc.
Failing tests for the known reason is no drama. However, these fails might hide real problems in the compiler and/or it's and stdint.h's C99-compliance. And reducing fail noise is always nice :-)
|
Mon 31 Oct 2011 10:15:47 AM UTC, comment #5:
Eric, what changes are you thinking of for better lint-friendliness?
|
Mon 31 Oct 2011 03:22:24 AM UTC, comment #4:
I would also like to remind our users that avr-libc is part of the overall GCC-based toolchain for the AVR, which includes:
- GNU Binutils (assembler, linker, utilities)
- GCC
- avr-libc
- GDB
The Eclipse code analyzer tool is not necessarily an official part of that toolchain. I agree in that, technically, the Eclipse-based tool needs to be taught GCC's extensions, especially attributes.
But, I can also agree with Joerg in that making avr-libc's more lint-friendly might be a good idea too.
My only personal caveat is that this is something that is low priority for the avr-libc developers/maintainers. (We already have enough changes planned in the future for the header files.) I would be willing to accept outside patches to do this, if they are shown to be useful and don't break avr-libc.
I'm lowering the Priority and Severity accordingly.
|
Sun 30 Oct 2011 10:37:31 AM UTC, comment #3:
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).
|
Sun 30 Oct 2011 09:38:58 AM UTC, comment #2:
On a second thought: generally preparing our header files for
being more lint-friendly might be a good idea. Everything
should be wrapped within #ifdef __lint where needed. This
should in particularly consider the commonly used "splint"
utility, but if Eclipse is using something differently, this
could be covered as well.
Btw., IIRC, the attribute-based integer types have been
introduced since they are completely unaffected by the
-mint8 compiler option.
|
Sun 30 Oct 2011 08:52:45 AM UTC, comment #1:
At a first glance, I'm against it. _attribute_ is a pretty
standard GCC feature, used heavily everywhere in library
code, so Eclipse should teach their parser about it if they
insist on parsing system headers/libraries.
I'm open for discussions about that though.
|
Sun 30 Oct 2011 08:06:15 AM UTC, original submission:
The eclipse 3.7.1 code analyser throws heaps of errors because it doesn't parse _attribute_(), and then doesn't find methods because it thinks they're different because their arguments don't match.
For example unsigned char would be compatible with uint8_t, except it's typedef'd as unsigned int when _attribute_() is ignored.
Change typedefs to give a correct result even without _attribute_(), which is ignored by gcc but does matter elsewhere. Without having tried I'd expect the same problem with lint.
|