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:	<10202071516.AA29586@clio.rice.edu>
Subject:	Re: conflicting types for bzero (gcc303)
To:	eliz AT is DOT elta DOT co DOT il
Date:	Thu, 7 Feb 2002 09:16:49 -0600 (CST)
Cc:	djgpp-workers AT delorie DOT com, ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De
In-Reply-To:	<7377-Thu07Feb2002075855+0200-eliz@is.elta.co.il> from "Eli Zaretskii" at Feb 07, 2002 07:58:55 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

> > There is a small possibility that 
> > someone is using the return argument today - and I don't think
> > breaking it in a "refresh" is the right thing.
> 
> If there is such a program, it is already broken by GCC 3.x, since
> the inline code emitted by GCC for bzero and bcopy behaves like GCC's
> own internal prototype says: it doesn't return anything.

There are lots of programs broken by GCC 3.x - and a lot of people 
are continuing to use GCC 2.x versions because of it.  Just because
GCC 3.x has done it, we shouldn't force people to change programs
after installing a refresh (it's supposed to fix bugs, not break anything).

> > In addition, I don't believe anyone has the time and energy right 
> > now to try to rebuild libc/binaries/re-test changes to a v2.03 refresh 
> > - I was hoping for a quick and easy distribution fix (which might
> > go in with the djtypes.h fix).
> 
> I don't think we need to test that at all, at least not for GCC 3.x,
> because they already use the code which doesn't return anything,
> unless they say -fno-builtin.

If we re-build the library, binaries and distributions I believe we 
should re-test before release.  Build procedures and hardware have 
failed in the past.  I've been burned too many times with "small" 
changes breaking big things because of inadquate testing.

It may be a personal fault - but I refuse to release things to
others without testing it myself.

The changes (djtypes.h, readme.1st, maybe an ifdef in string.h) would
only trigger for GCC 3.x - and only in areas we know problems 
already happen.  This would not change any of the binaries or
libraries already built (and is fairly quick to put in distributions
and test).

> I think we will have to answer lots of FAQs if we don't take the
> opportunity of this refresh to fix that.

I agree with the idea - I'm just saying I don't have the time to do a
new binary distribution before June at the earliest.  I think an
appropriate ifdef could fix the FAQ issue with 1/100th the effort of
changing source distributions, rebuilding libraries, rebuilding 
binaries, test releases, etc.

- Raw text -