Date: Thu, 1 May 2003 10:22:51 -0500 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: "Andrey A. Chernov" <ache@nagual.pp.ru> Cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols Message-ID: <20030501152251.GB34992@madman.celabo.org> In-Reply-To: <20030501151458.GA54182@nagual.pp.ru> References: <20030430062647.GA82023@rot13.obsecurity.org> <20030430143121.GK39658@survey.codeburst.net> <20030430152708.GA26216@madman.celabo.org> <20030430153645.GL39658@survey.codeburst.net> <20030430164135.GB26508@madman.celabo.org> <20030501140255.GB1869@survey.codeburst.net> <20030501143032.GA34163@madman.celabo.org> <20030501144600.GC1869@survey.codeburst.net> <20030501145345.GA34884@madman.celabo.org> <20030501151458.GA54182@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 01, 2003 at 07:15:01PM +0400, Andrey A. Chernov wrote:
> On Thu, May 01, 2003 at 09:53:45 -0500, Jacques A. Vidrine wrote:
> >
> > A libc consumer (getpwent.c):
> > 587 namesize = _strlcpy(&keybuf[1], name, sizeof(keybuf)-1);
>
> IMHO, it is bad hack at whole, and all namespace.h tricks should be
> removed.
>
> The reason is quite simple. Yes, you can save libc this way, but what
> happens, if application linked, say, with libc AND libncurses (insert any
> other system library here)? libc will be saved, but libncurses will not.
> It means, to be logically, you need to replace strlcpy with _strlcpy in
> ALL FreeBSD libraries. Better way is stop doing half-singing -
> half-dancing and produce linker error when application attempts to replace
> any function in standard namespace. It automatically makes impossible
> broken binary-only packages.
>
> So, I vote for namespace.h removing (i.e. all _ tricks). Who with me?
I'm with you ... as long as:
(a) We then post-process libraries (or object files) to
automagically handle the symbols (all of them, or maybe just
those not covered by some standard we pick in the case of libc).
e.g. something such as
objcopy --weaken ${.IMPSRC} ${.TARGET}
but a bit more work.
(b) We give Daniel and others working on threaded libraries a chance
to discuss the special needs there. (That _is_ why namespace.h
was originally created. We do need to handle stubs somehow; weak
symbols alone are not enough.)
(c) We do it after 5.1-RELEASE, and before 5.2-RELEASE; or we only
do it in 6.x.
(d) I don't have to do it all.
Cheers,
--
Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal
nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501152251.GB34992>