From owner-freebsd-current Wed Jan 12 21:16:31 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 7A32814E20 for ; Wed, 12 Jan 2000 21:16:27 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id VAA24638; Wed, 12 Jan 2000 21:16:25 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id VAA22974; Wed, 12 Jan 2000 21:16:25 -0800 (PST) (envelope-from obrien) Date: Wed, 12 Jan 2000 21:16:25 -0800 From: "David O'Brien" To: jasone@canonware.com, current@freebsd.org Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp. Message-ID: <20000112211625.A21988@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20000112172213.Z302@sturm.canonware.com> <200001130300.TAA74514@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001130300.TAA74514@vashon.polstra.com>; from jdp@polstra.com on Wed, Jan 12, 2000 at 07:00:01PM -0800 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 12, 2000 at 07:00:01PM -0800, John Polstra wrote: > > The buildworld problem that I introduced is due to cc_fbsd directly > > compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my > > opinion a questionable practice, since it adds dependencies to the > > internals of the libc code, which has just been proven to bite. =) > > Yes, I agree. I disagree. :-) I don't see why a plain function like mkstemp() should be written so specially. Couldn't all the hiding/changing done for threads be done w/in open() itself? Neither HP-UX 10.30 (which has kernel threads), nor Solaris 7 needs such open() hackery in mkstemp(). > I _really_ don't like it when a program reaches waaaaaaay over into an > unrelated directory for its sources. We already do that all over the place. :-) > I'd rather have a few duplicated sources. I dissagree. Then we have the problem of fixing a PR/bug in one source but not the other. The use/making of temperary files is already a security issue. I can just see it happen that someone fixes a problem with one copy of the source and then we find we still have some vulerabiltity because the second copy wasn't known/found/fixed. > 5) Maintainers of the build tools should be very careful to ensure > that their tools use only the minimum, universally-available > functionality from libc. GNU provides a copy of mkstemps() in libiberty. It looks like I should reconsider importing it *again*. The problem is there is no one true "libiberty". Rather than being an offical library maintained as itself, "libiberty" is what any GNU program calls the libarary of "compatibility"/portability functions needs. Thus libiberty in binutils is a totally different beast than the GCC 2.95 libiberty, than the .... [oh how I wish the GNU organization would put its head on straight sometimes] -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message