Date: Thu, 1 May 2003 14:56:51 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: "Jacques A. Vidrine" <nectar@freebsd.org>, John Baldwin <jhb@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols Message-ID: <p05210606bad719ae40fc@[128.113.24.47]> In-Reply-To: <20030501182820.GA53641@madman.celabo.org> References: <Pine.BSF.4.21.0305011046140.73226-100000@InterJet.elischer.org> <XFMail.20030501140549.jhb@FreeBSD.org> <20030501182820.GA53641@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 1:28 PM -0500 5/1/03, Jacques A. Vidrine wrote: >On Thu, May 01, 2003, 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. I think the "big picture" is that many people simply do not agree with your premise. It is not that they are obsessed with the strlcpy() example, but they're using that example to (try to) explain why they disagree with your basic premise. As for me, I'm not quite sure what I think about the big picture. For something like strlcpy, I'm tempted to say "if the user wants to override the routine, then let them. If they get into any trouble, then that's their problem.". However, I can imagine situations where I might not be so cavalier. Let's say the fooblah() routine works by taking advantage of some internal implementation details of a routine called somestd(). Thus, someone could provide a perfectly 100% correct somestd() routine, and they would still break the fooblah() routine, because fooblah() is "cheating" in how *it* uses somestd(). I guess I'd say that for any routine X(), if X() depends on some undocumented (implementation-specific) details of routine Y(), then we should have a _Y() routine for X() to call. Maybe even call it _libc_internal_Y(), to emphasize why it exists, and why X() is calling that instead if Y(). That is my thinking so far on the big picture. I won't even claim that is my final opinion, as I'm sure I could be swayed by a good counter-argument. However, I'm hoping this will help a little bit, just because I'm talking about a generic rule that would cover any routines of X() and Y(). -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05210606bad719ae40fc>