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

[Weddington, Eric]

> -----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.

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?

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.)

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.

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.

Eric