bugAVR C Runtime Library - Bugs: bug #34695, fixed width int types without...

 
 

bug #34695: fixed width int types without __attribute__()

Submitted by:  Volker Kuhlmann <vok>
Submitted on:  Sun 30 Oct 2011 08:06:15 AM UTC  
 
Category: HeaderSeverity: 1 - Wish
Priority: 9 - ImmediateItem Group: Header files
Status: NonePercent Complete: 0%
Assigned to: NoneOpen/Closed: Open
Release: 1.7.1Fixed Release: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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.

Eric Weddington <arcanum>
Project Administrator
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)

Georg-Johann Lay <gjlayde>
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 :-)

Georg-Johann Lay <gjlayde>
Mon 31 Oct 2011 10:15:47 AM UTC, comment #5:

Eric, what changes are you thinking of for better lint-friendliness?

Volker Kuhlmann <vok>
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.

Eric Weddington <arcanum>
Project Administrator
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).

Volker Kuhlmann <vok>
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.

Joerg Wunsch <joerg_wunsch>
Project Administrator
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.

Joerg Wunsch <joerg_wunsch>
Project Administrator
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.

Volker Kuhlmann <vok>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #25969:  stdint-16.h added by gjlayde (3kB - text/x-chdr - GCC's understanding of stdint types)
file #25970:  stdint-mint8.h added by gjlayde (3kB - text/x-chdr - GCC's understanding of stdint types)
file #24247:  avr-libc-1.7.1_stdint.diff added by vok (1kB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by gjlayde (Posted a comment)
  • -unavailable- added by arcanum (Posted a comment)
  • -unavailable- added by joerg_wunsch (Posted a comment)
  • -unavailable- added by vok (Submitted the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 16 Nov 2012 06:54:53 PM UTCarcanumPriority1 - Later=>9 - Immediate
    Fri 01 Jun 2012 11:08:08 AM UTCgjlaydeAttached File-=>Added stdint-16.h, #25969
      Attached File-=>Added stdint-mint8.h, #25970
    Mon 31 Oct 2011 03:22:24 AM UTCarcanumSeverity3 - Normal=>1 - Wish
      Priority5 - Normal=>1 - Later
    Sun 30 Oct 2011 08:06:15 AM UTCvokAttached File-=>Added avr-libc-1.7.1_stdint.diff, #24247

    Back to the top


    Powered by Savane 3.1-cleanup