This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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]>"?Yes.If that's the pattern, grep says iconv.c also needs fixing. If you can confirm that, I will fix those instances. Thanks.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?
Yes.
If there are some patterns broken, I want to grep and fix them. Sorry for breaking things.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |