Date: Thu, 8 May 2003 17:12:24 +0100 From: Paul Richards <paul@freebsd-services.com> To: "Jacques A. Vidrine" <nectar@FreeBSD.org>, David O'Brien <dev-null@NUXI.com>, freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols Message-ID: <20030508161223.GL1869@survey.codeburst.net> In-Reply-To: <20030506175557.GE79167@madman.celabo.org> References: <Pine.BSF.4.21.0305011046140.73226-100000@InterJet.elischer.org> <XFMail.20030501140549.jhb@FreeBSD.org> <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506170919.GD36798@dragon.nuxi.com> <20030506175557.GE79167@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 06, 2003 at 12:55:57PM -0500, Jacques A. Vidrine wrote: > On Tue, May 06, 2003 at 10:09:19AM -0700, David O'Brien wrote: > > On Mon, May 05, 2003 at 12:54:28PM -0500, Jacques A. Vidrine wrote: > > > > > I'm backing out the commit in good faith and in the hopes that the > > > > > big picture comes more clearly into focus. > > > > > > > > Thanks. > > > > > > Do you also want to `fix' the other ports that define their own strlcpy? > > > > Ports have maintainers. Please create a PR for them. > > But gee, the problem is that the ports themselves are not really > in error, unless one is a standards fascist that believes that an > application can never define any function that might be in some > standard's namespace. Any C code that isn't written according to the standard that defines C is broken. There's just no argument to be made that FreeBSD should be hacked to support C code that is written by programmers who haven't bothered to learn the rules of C properly. That's not to say there aren't a lot of crap programmers out there who don't know what they're doing but FreeBSD should not be bending over backwards to make their code work, we should just leave it be broken. In the case you've cited throughout this thread, where libc calls into an application's implementation of a reserved symbol, this breaks nothing except the application, which was where the real bug existed. The only benefit that your solution offers is that broken code *may* work better. The downside, is people who really know what they're doing and deliberately want to override a standard function need to jump through extra hoops that they won't even be aware of. My opinion is that FreeBSD should cater to the people who know their stuff and let the crap programmers out their be shown the bugs that exist in their code when they try to use it on FreeBSD. I want FreeBSD to be the environment where I can develop my code with a high degree of confidence that I'm doing things right and for FreeBSD to show up the problems if I'm doing it wrong. I don't want to find that FreeBSD was hiding my own inadequacies from me :-) In that light, if I implement a broken strlcpy and my application falls over in a heap because libc calls it then I should have learnt an important lesson about how to write C correctly. If FreeBSD hides/protects me from this sort of mistake in my coding then I don't think it's upholding and encouraging a high standard of coding. -- Paul Richards
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030508161223.GL1869>