This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Fwd: POSIX 2008 C Extensions and restrict Keyword
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: "Jonathan S. Shapiro" <shap at eros-os dot org>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Tue, 9 Jul 2013 13:23:18 -0500
- Subject: Re: Fwd: POSIX 2008 C Extensions and restrict Keyword
- References: <51DC150C dot 1010109 at oarcorp dot com> <51DC3353 dot 5050401 at LGSInnovations dot com> <CAAP=3QPoTPnUpc2f0YXFkwzPNk4QaiDQZPuWbhG7eRy9yGR-Qg at mail dot gmail dot com> <CAAP=3QOq5M+zQDv2_f9RsXYsqGt8T-qvx_kkuMrS7X=zzhFbRA at mail dot gmail dot com>
On 7/9/2013 12:25 PM, Jonathan S. Shapiro wrote:
Sorry - meant this for the list
On Tue, Jul 9, 2013 at 8:59 AM, Craig Howland
<howland@lgsinnovations.com> wrote:
Assuming that it is done, however, we should use restrict, not __restrict. The latter apparently dates from 2000 when the keyword was brand new. Since it is now pushing 14 years, I suggest that updating sys/cdefs.h to get rid of the __ is in order....
This is a particular case of a general argument. I should think the
right way to proceed is to document that newlib requires compliance
with at least {list of standards}, and then go through more generally
and clean out stuff intended to support obsolete compilers.
I tend to be cautious and not want to remove the __restrict alternative.
It is easy to add it and have it be conditional. If it means anything, it
appears glibc has these also.
My general concern is that I don't mind starting to fix a .h file and
its associated code -- one at a time. But I want some guidelines so
this isn't anymore painful than it has to be. :)
Two caveats:
1. Some embedded targets are still stuck on legacy compilers. I don't
know how many, which ones, and whether we should care.
2. Visual C, in particular, has haphazard standard support. Again, I
don't know if this compiler is of any interest for newlib. Visual C++
2011 still doesn't comply with C99. Visual C++ 2013 plans
improvements, but not complete compliance. Where C99 is supported, it
is often with non-compliant syntax, semantics, and keywords. Which
defies any definition of "support" that I comprehend, but there it is.
On the bright side, WIndows users can always use the Intel compiler,
which does support newer standards fully.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985