Date: Tue, 6 May 2003 09:42:04 -0600 From: Ben Mesander <ben@timing.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols Message-ID: <16055.55244.458061.779430@piglet.timing.com> In-Reply-To: <Pine.GSO.4.10.10305051855570.10283-100000@pcnet1.pcnet.com> References: <20030505225021.GA43345@nagual.pp.ru> <Pine.GSO.4.10.10305051855570.10283-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen writes: > On Tue, 6 May 2003, Andrey A. Chernov wrote: > > On Mon, May 05, 2003 at 18:14:45 -0400, Daniel Eischen wrote: > > Especially when I don't understands threads details. At this stage we just > > discuss here how to make things better. My point will be clear answering > > on this simple question: > > > > What produce less errors in application and libraries? > > a) Allow application to replace any standard function. > > I thought Jacques found lots of ports that replaced standard > functions... In addition to ports which override libc functions like printf() for ease of porting, there are important ports, such as the Boehm garbage collector for C/C++ or electric fence, which _depend_ upon the ability to override libc functions such as malloc() and free(). Whatever decision is eventually made must allow such ports to function. This has been brought up once before, but I do not see how any of the advocates for change have addressed it. --Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16055.55244.458061.779430>