Date: Thu, 01 May 2003 14:45:02 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: "Jacques A. Vidrine" <nectar@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols Message-ID: <XFMail.20030501144502.jhb@FreeBSD.org> In-Reply-To: <20030501182820.GA53641@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01-May-2003 Jacques A. Vidrine wrote: > On Thu, May 01, 2003 at 02:05:49PM -0400, John Baldwin wrote: >> Agreed. Somebody just needs to sit down and fix the qpopper port and >> then the argument for this change goes away and it can be reverted. > > qpopper is not the point. The qpopper port was fixed just a couple of > hours after I made the commit to libc. (I had sent the qpopper patch > to the port maintainer earlier.) Preventing the bogus behavior from > ever happening again was the point. > > A lot of folks are focused on qpopper and strlcpy. I believe that > the big picture is being missed. I moved this thread to freebsd-arch > so that we could discuss how to hide all (or most, or non-standard) > symbols in libc. Not so that we could argue about this particular > commit. It seems that many people don't think the symbols in libc need hiding. What is the reason to prevent a user from overriding the functions used by libc? malloc() and free() are an example you agree to, and I don't think we should hide things willy-nilly. There are many uses for overriding symbols in libc that I'm sure neither of us have thought of. Why artificially limit it? -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030501144502.jhb>