Date: Thu, 1 May 2003 19:15:01 +0400 From: "Andrey A. Chernov" <ache@nagual.pp.ru> To: "Jacques A. Vidrine" <nectar@FreeBSD.org>, Paul Richards <paul@freebsd-services.com>, freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) Message-ID: <20030501151458.GA54182@nagual.pp.ru> In-Reply-To: <20030501145345.GA34884@madman.celabo.org> References: <20030430043303.GA46365@mero.morphisms.net> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501151458.GA54182>