Date:	Wed, 28 Jun 2000 16:08:43 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Laurynas Biveinis <lauras AT softhome DOT net>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: libc/stubs business
In-Reply-To:	<3959BB59.1A6624DF@softhome.net>
Message-ID:	<Pine.SUN.3.91.1000628160436.526C-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 Wed, 28 Jun 2000, Laurynas Biveinis wrote:

> > As for tempnam, it is called by tmpfile, which is ANSI, and so the
> > fact that tempnam calls access (a non-ANSI function) is a problem.
> 
> Below is a patch. OK to commit?

Yes.  But this doesn't fix the tempnam problem, does it?

> > I think it could be a good idea to get libc build procedure to run
> > libclink/check automatically when the library is built, and abort the
> > build if something fails to check out.  
> 
> I see it more as a part of 'make test' or 'make check', not simple make.
> IMHO it is better to separate building and testing process.

I don't think this is a test.  It is no more a test than the fact that we 
use a lot of -W* switches, to reveal possible bugs.  I think that 
polluting ANSI/Posix namespace is a grave problem, and if an automated 
tool finds quite a few problems, even after several cleanup efforts, it's 
a clear sign that manual procedures are inadequate.

> Will see, probably. For me DJGPP issues is a snowball rolling of the mountain
> nowadays - it gets bigger and bigger :-)

Welcome to DJGPP development ;-)

- Raw text -