Date:	Tue, 25 Apr 2000 11:16:25 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Martin Str|mberg <ams AT ludd DOT luth DOT se>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: restrict
In-Reply-To:	<200004241330.PAA28666@father.ludd.luth.se>
Message-ID:	<Pine.SUN.3.91.1000425111359.23128C-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, 24 Apr 2000, Martin Str|mberg wrote:

> > > Or can we demand that users of DJGPP v. 2.04 use gcc 2.95.2?
> > 
> > I would like to avoid requiring specific versions of GCC, unless we
> > absolutely must.
> 
> But then we would have the problem of libc headers not matching libc
> compilation.

I don't think this will do any trouble in the context of library
functions and __restrict__.

When compiling the library, __restrict__ simply conveys to the
compiler information about the arguments, and allows it to perform
some optimizations based on that information.  If we document those
assumptions in libc.info, we don't need to worry about compilers which
don't understand __restrict__: code that behaves according to these
assumptions will clearly work, while code that breaks them is
incompatible with C99, and should not be used with the C99-compliant
library.

In other words, __restrict__ is a tool to force the code into
compliance with what the library functions expect.  But nothing
prevents a compliant code to call library functions if the compiler
doesn't understand what __restrict__ is.

> And where to put that? In every file that needs it or some kind of
> general file?

DJ suggested libc/features.h or some such, to be included by all other
headers.

- Raw text -