Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline...

[David Brown]

On 24/07/2012 16:30, Weddington, Eric wrote:
> > -----Original Message----- From:
> > address@hidden
> > [mailto:avr- address@hidden
> > On Behalf Of David Brown Sent: Tuesday, July 24, 2012 1:40 AM To:
> > address@hidden Subject: Re: [avr-libc-dev] [bug #36921]
> > util/delay.h uses inline...
> >
> > On 23/07/12 21:00, Joerg Wunsch wrote:
> > > As Weddington, Eric wrote:
> > >
> > > > I would hate to say, "We have to use C99 for some avr-libc
> > > > modules (atomic.h), but we guarantee C89 compliance for other
> > > > avr-libc modules (delay.h)". We really should be consistent
> > > > across the whole project. Which means that if we guarantee C89
> > > > compliance for one module, then it needs to be guaranteed for
> > > > everything in avr-libc, and we document what standard we comply
> > > > too.
> > >
> > > I'd say we *guarantee* C99 compliance, but wherever compliance
> > > to older standards could be reasonably had, I don't mind
> > > maintaining it that way.
> > >
> > > Whenever compliance to C89/C90 would require a tradeoff, C99
> > > takes precedence.  However, writing a couple of underscores in
> > > front of a keyword is nothing worth talking about, I think.
> > >
> > > > Another data point: In the somewhat "standard" Makefile that we
> > > > put together for AVR applications, we always set the --std flag
> > > > to gnu99 for compiling AVR applications.
> > >
> > > Well, "gnu99" is yet another thing, we should make sure
> > > everything works with "c99" (i.e., without the GNU extensions).
> >
> >
> > For my 2 øre, I agree mostly with this.  In the case of adding a
> > couple of underscores, it should not be too much hardship.  But I
> > also see Erik's point - how much should people bother making
> > headers C89 compatible if few people use it that way, and other
> > headers will never be C89 compatible?
> >
> > Is it really practical to use avr gcc without gnu extensions?
> > What about "pedantic" mode?
> >
> > One case that springs to mind here is when people have to follow a
> > particular coding standard, such as Misra (which is C89 based,
> > IIRC), or who have to program in a particular variant such as
> > strict ANSI.  It is very useful in such cases to be able to compile
> > the code in C89 or ANSI mode, since that lets the compiler spot
> > errors better.  Should these users be told that they can use most
> > of the library, excluding specific parts such as atomic.h, or
> > should they be told that nothing is going to work?
> >
> >
> > Do the C99-specific headers check __STDC_VERSION__ to give a
> > user-friendly error message if someone tries to use them in C89
> > mode?
> >
> >
> > Finally, I hope all the headers are also C11 compliant for the
> > future... (from what I've read of C11, I can't see any reason why
> > not).
>
> A lot of great points above.
>
> I agree that talking about 2 underscores is really not that much.
>
> I guess it's the larger issue of "What standard does avr-libc comply
> to? And what standard should avr-libc comply to?" that I'm concerned
> about.
>
> I can agree that we meet some *minimum* standard, such as C99.
> Obviously that's a reasonable goal.

Agreed - though it is possible that some parts might require gcc 
extensions to C99.  What should be done if gcc extensions are not 
required, but would allow the generation of better (smaller/faster) 
code?  One possible situation here is when attributes such as "const" or 
"pure" would allow better optimisation.

> Is it ok to have some modules that comply to C89, and others that can
> never comply to C89? How would that benefit the user?

Assuming that the C89-compliant modules are also C99-compliant, I think 
it would benefit those who still have to use C89.  While all 
(non-pathological) code that is valid C89 is valid C99, there are 
benefits in compiling your C89 code in C89 mode.  The most obvious is 
static error checking - if you have to write C89-valid code, then it is 
useful that your compiler reminds you that // comments are not allowed.

> The MISRA standard could be important. We would need to find out what
> C standard it is based on. However, GCC itself does not have a
> feature to compile to MISRA (AFAIK) so it makes it difficult to fully
> comply. (Though I've wanted to add that feature to GCC for years.)

MISRA is currently based on C90/ANSI, AFAIK, with a C99 revision due 
"real soon now".  However, you can expect the old version to be the norm 
for a long time to come.

gcc can compile perfectly well to MISRA standards - but what it can't do 
is give warnings for violations of many MISRA rules in the way that some 
compilers (IAR, CodeWorrier, etc.) can.  Adding such warnings to gcc 
would be nice - but it should be a job for upstream gcc, not avr-gcc. 
Not all MISRA rules can be checked by the compiler, of course.

(I don't use MISRA myself, I just know a little bit about it.)

> I do think that perhaps we ought to start using __STDC_VERSION__ to
> give user-friendly error messages so that way we don't run into this
> issue again. This goes beyond just the adding of two underscores for
> delay.h.

I think it is perfectly reasonable to make some modules C99-only (or 
dependant on gcc extensions), if it leads to better/clearer code - but I 
agree there should be a check on versions and a nice #error message 
suggesting the use of "--std" flags.

> And lastly, I don't know much about C11 to say, but I would think
> that at the least it would be a superset of C99.

I think you have to try very hard to make C99 code that is not C11 
compatible.  But there are a symbols that are defined in new header 
files that might theoretically conflict with other headers (though I 
can't think of any realistic examples for avr libc).

One interesting area where avr libc and C11 might have different, 
potentially conflicting approaches is for atomic accesses.  I haven't 
looked at either avr libc or C11 API's closely enough to judge.

<http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29>

mvh.,

David


> Eric