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: from "Eli Zaretskii" at Jan 27, 2002 10:56:04 AM X-Mailer: ELM [version 2.5 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Precedence: bulk > 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.