This is the mail archive of the
mailing list for the newlib project.
Re: restrict in comments was Re: Patch - Add restrict to time.h
- From: Craig Howland <howland at LGSInnovations dot com>
- To: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Mon, 25 Nov 2013 17:20:08 -0500
- Subject: Re: restrict in comments was Re: Patch - Add restrict to time.h
- Authentication-results: sourceware.org; auth=none
- References: <52923B56 dot 8060408 at oarcorp dot com> <3862C5643B15B6468269546753EB2A92096B9C07 at BLTSXVS01 dot govsolutions dot com> <52937EC5 dot 5010503 at oarcorp dot com> <5293869B dot 90301 at LGSInnovations dot com> <52938F79 dot 8000605 at oarcorp dot com>
On 11/25/2013 12:57 PM, Joel Sherrill wrote:
As far as I'm concerned, it should be plain "restrict" in the documentation
sections, because it is a standard keyword. (The only question would be if we
wanted a general comment in a boilerplate section that mentions restrict being
subject to compiler support.)
On 11/25/2013 11:19 AM, Craig Howland wrote:
On 11/25/2013 11:45 AM, Joel Sherrill wrote:
On 11/25/2013 10:41 AM, Howland Craig D (Craig) wrote:
So change "restrict<[s]>" to "restrict <[s]>"?
If that's the pattern, grep says iconv.c also needs fixing.
If you can confirm that, I will fix those instances.
Yes, iconv.c also needs to be tweaked (I missed that one earlier). (The
"<[string]>" construct ends up making "string" bold in the PDF version of the
manual, but no other alteration. So, for example, "char *restrict<[s]>,"
becomes "char *restricts," instead of the desired "char *restrict s,".)
OK. I committed a fix for these as obvious.
Now I want to double check that we said use "restrict" not
"__restrict" in the documentation section.
And does "char *<X>" format correctly with the "*<" adjacent?
If there are some patterns broken, I want to grep and fix
them. Sorry for breaking things.