Date: Wed, 30 Apr 2003 14:37:24 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) Message-ID: <3EB04214.BD79BC80@mindspring.com> References: <20030430004907.GA32349@mero.morphisms.net> <20030430031856.GA20258@madman.celabo.org> <20030430144149.GA7786@dragon.nuxi.com> <20030430002014.GA1190@dragon.nuxi.com> <Pine.GSO.4.10.10304300024280.1846-100000@pcnet1.pcnet.com> <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> <20030430154936.GA58835@mero.morphisms.net> <200304301646.h3UGklUx051071@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman wrote: > <<On Wed, 30 Apr 2003 11:41:35 -0500, "Jacques A. Vidrine" <nectar@FreeBSD.org> said: > > Package X defines a function named `strlcpy', that works well for > > Package X and may or may not have any relationship to the `strlcpy' > > we all know and love from OpenBSD. > > > Which of the following scenarios is the least astonishing? > > Secnario 4. Package X fails to build with a linker error because the > user has attempted to define something that he is not entitled to > redefine. (No, I don't know how to accomplish this with our existing > toolchain.) There is an expectation by users of being able to replace libc functions with instrumented versions. If they replace them with buggy versions, as well, they have to expect that their code will end up being buggy. As far as internal use of libc functions by libc functions, it's problematic: for example, if someone implemented their own heap managing malloc library that called things like sbrk directly, then overriding their choice of function could have consequences. Likewise, a profiling library that wrapped entry an exit into C library functions would get false readings for the functions. That said, for dynamically linked objects, there is support for a special "handle" value of RTLD_NEXT when calling dlsym(), according to POSIX/SUS2. FreeBSD supposedly supports this, and it could be used to navigate the object tree to get the "right" symbol. Also, for libc functions without side effects, the caller could directly reference the strong symbol version, if it believed it to be necessary, and was willing to have profiling time accounded against it instead of against the function it was calling (thus artificailly inflating the expense). Personally, I feel that the ability to override library functions is more important than the ability to link buggy code and have it function anyway, so I'd leave things alone. 8-). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EB04214.BD79BC80>