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 Joerg
> Wunsch
> Sent: Monday, July 23, 2012 9:56 AM
> To: address@hidden
> Subject: Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline...
> 
> The policy is to be as liberal as reasonably possible. ;-)

Well, is it? We can make whatever policy is reasonable...
 
> In the current case, replacing the "inline" by "__inline" (to force it
> into the implementation namespace) is no big deal, so I'd take that
> route.  OTOH, Dean Camera's <util/atomic.h> implementation would not
> be possible that way without using the C99 addition to declare a
> variable within a "for" statement, so we documented it that way.
> 
> Most of GCC's extensions are available even with -std=c89 mode, by
> properly marking them as extensions, so that's what I meant with "as
> liberal as reasonably possible".  It doesn't cost us anything, but
> gives users the most possible flexibility.
> 
> Note that even GCC did not switch to default C99 mode yet; the default
> mode is still (as of GCC 4.7) "gnu89".

What GCC does for their project is, I think, somewhat irrelevant to us. GCC is 
in the (painfully slow) process of making sure that their code base compiles 
with the latest C++ compiler, so they can eventually start using C++ in their 
code base.

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.

Personally, I think that C89 is pretty old, and it's stupid when there is 
arguably a later existing standard: C99.

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. I *think* (I would have to look it up for sure) that even Atmel 
Studio 6 probably uses --std=gnu99 for compilation of AVR applications. 

Given all this, then why does avr-libc have to be tied to a c89 standard? To be 
compatible with what? What user is having difficulty with avr-libc such that 
they need avr-libc to comply with a c89 standard? And is that user in such a 
small minority? What problem is solved by having avr-libc comply to the older 
c89 standard?

Eric