Date:	Mon, 3 Apr 2000 17:34:18 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: restrict
In-Reply-To:	<Pine.LNX.4.10.10004031621080.2210-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.1000403172411.28814F-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 3 Apr 2000, Hans-Bernhard Broeker wrote:

> In short: we are not allowed to arbitrarily ignore 'const' and 'restrict'
> qualifiers in the standard headers. Looks like we'll have to sit down and
> check our libc implementation for 'restrict'-safeness.

Library functions being `restrict'-safe is not the problem that worries 
me.  What worries me is that if you put `restrict' into the standard 
headers, you momentarily lose compatibility to older versions of GCC.  
In effect, you *force* people to use GCC 2.9X, even if they don't need 
any of the new C99 functionality.  I don't like this tight coupling
between GCC and libc versions.

Perhaps there's some GCC feature that could help us.  For example, GCC 
could define some preprocessor symbol when invoked in C99-compatible 
mode, a-la __STRICT_ANSI__ which is defined under -ansi.  If so, we could 
define `restrict' away based on that symbol.

Can someone please look and/or tell whether GCC has some feature which 
might help?

If GCC doesn't have anything like that, we could of course invent some 
specs trickery, but that is not a clean solution (people tend to mess up 
their specs all the time).

I wonder what does glibc do about that.  Can someone please look?

- Raw text -