avr-libc
avr-libc copied to clipboard
avrdudes
[bug #34695] fixed width int types without __attribute__()
Sun 30 Oct 2011 09:06:15 AM CET
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.
file #24247: avr-libc-1.7.1_stdint.diff file #25970: stdint-mint8.h file #25969: stdint-16.h
This issue was migrated from https://savannah.nongnu.org/bugs/?34695
Joerg Wunsch <joerg_wunsch> Sun 30 Oct 2011 09:52:45 AM CET
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.
Joerg Wunsch <joerg_wunsch> Sun 30 Oct 2011 10:38:58 AM CET
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.
Volker Kuhlmann
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).
Eric Weddington
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.
Volker Kuhlmann
Eric, what changes are you thinking of for better lint-friendliness?
Georg-Johann Lay
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 :-)
Georg-Johann Lay
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.
Eric Weddington
This issue needs to be considered along with other stdint.h changes in bugs #36571, #35539.
Implemented as https://github.com/avrdudes/avr-libc/commit/73af2a2a924e7b38bc99452c02b0d21c86cc12d2.
