X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10201271804.AA18350@clio.rice.edu>
Subject:	Re: GCC 3.x and bcopy
To:	djgpp-workers AT delorie DOT com
Date:	Sun, 27 Jan 2002 12:04:12 -0600 (CST)
Cc:	eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
In-Reply-To:	<Pine.SUN.3.91.1020127105225.14549L-100000@is> from "Eli Zaretskii" at Jan 27, 2002 10:56:04 AM
X-Mailer:	ELM [version 2.5 PL2]
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

> Does the v2.03 refresh correct the problem with bcopy?  

No, I wasn't aware of any and no one mentioned it.  

> Our prototype 
> says it returns a `void *' (and bcopy's code indeed behaves like that), 
> but GCC's built-in bcopy returns nothing.  This causes warnings in any 
> program that includes string.h and is compiled by GCC 3.x without -ansi.

I've got a couple of problems putting this into a V2.03 refresh:

1) It's an interface change.  Maybe someone's using the return value
   someplace for something?
2) The refresh is already done and on Simtel - I wasn't planning on
   updating any libraries or binaries (the time consuming part).
3) Testing?

The current refresh++ idea was to replace a couple of files (readme.1st
plus add an ifdef for va_list to support GCC 3.1 builds).  Replacing
a text documentation file is low risk and low effort.  The ifdef for
va_list has been in CVS for over a year, so it's just a matter of
making sure it doesn't break something else.  So I wanted to do a 
few builds of things with it under several versions of GCC before I
suggested a replace of the refresh.   This may take several weeks at
best.  GCC 3.1 may be out first :-(

> I'd like to avoid the flood of FAQs about this, if it's possible.

I don't see a quick fix for this one.

> The cure is simple: modify the prototype in string.h, and change bcopy.c 
> to not return anything.

Changing the prototype to an incompatible one, changing all the distributions,
rebuilding the libraries and binaries, plus changes to documentation for 
the change is not so simple.  The current distributions have gone through
5 weeks of beta and 3 weeks of release - I'm never comfortable making 
any changes - much less major changes - without a good set of testing.

So in summary, I don't like the effort+risk/reward ratio to suppress some 
warnings.  

Could we - should we? - create an ifdef in string.h for the bcopy prototype?
This would break building the 2.03 library with GCC 3.x but would retain
current 2.03 behavior for old programs under GCC 2.x.

- Raw text -