This is the mail archive of the
mailing list for the newlib project.
Re: Patch: Add __restrict to string.h
- From: Craig Howland <howland at LGSInnovations dot com>
- To: newlib at sourceware dot org
- Date: Mon, 22 Jul 2013 11:20:33 -0400
- Subject: Re: Patch: Add __restrict to string.h
- References: <6n1db1hws1heh5xc9vllbm19 dot 1374187318673 at email dot android dot com> <20130719095503 dot GA20871 at calimero dot vinschen dot de>
On 07/19/2013 05:55 AM, Corinna Vinschen wrote:
We should be using "restrict" everywhere, not only in the docs. The C standard
defines restrict as a keyword, just as it does const, volatile, etc. And it has
been standard for more than 13 years. We do not use __const in headers, even
though before C89 it was not standard but available as a GCC extension. So
while 15 years ago using __restrict would have made sense, it is not appropriate
On Jul 18 17:42, Joel Sherrill wrote:
I was leaning that way but waffled. Anyone else want restrict in the docs?
Yes, that makes sense, following SUS docs.
$ cd libc/include
$ grep __const *.h | wc -l
$ grep const *.h | grep -v __const | wc -l
I do realize that this does not fit exactly with the sys/cdefs.h which has
recently been brought into sync with FreeBSD, but this would be a trivial
difference. This type of thing--having gratuitous differences from the
standard--will only lead to confusion and questions among the majority of
maintainers. Why is it this way? Etc. Then we'll need someone in the know to
explain. You get the point. While I do see the advantages of trying to be the
same, we should not be blindly using someone else's excess baggage (or
13.5-year-old extension diction).
We're making a new start on restrict in newlib. (Thank you, Joel, for starting
the ball rolling.) We should make it clean.
(Sorry for the lag on this, but I was away. Joel, if you'd like, I'd even edit
your patch to make the change.)