X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Mon, 6 Mar 2000 15:42:31 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	DJGPP-WORKERS <djgpp-workers AT delorie DOT com>
Subject:	Re: iso646.h and some questions
In-Reply-To:	<Pine.SUN.3.91.1000305154441.2134B-100000@is>
Message-ID:	<Pine.LNX.4.10.10003061537270.14313-100000@acp3bf>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 5 Mar 2000, Eli Zaretskii wrote:

> > Shall I send header files containing new functions, so other people
> > can start implementing them?
> 
> IMHO, the prototypes should be added to the headers only *after* the
> functions are already available.  Otherwise, we might get conflicts (when
> building a package that provides its private versions of the missing
> functions), and some people think that the existence of a prototype is an
> evidence that the function is provided by the library. 

I oppose to this point. As long as there are, indeed, plans to implement
these functions in the near future, I think it's best to put in the
prototypes right now, as a method of staking a claim. Among others, it may
help catching unwary program authors that use names now reserved by the
new standard library, for their own purposes. They'll get compiler error
messages about conflicting prototypes, early, instead of having to rewrite
their programs, later on. 

Given that these are standardized functions, there's no risk we'll break
any compatibility unwillingly by getting those prototypes wrong, either,
so let's just put them in.

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -