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 ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
