|
From: | David Brown |
Subject: | Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline... |
Date: | Tue, 24 Jul 2012 17:18:20 +0200 |
User-agent: | Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |