Date: Tue, 06 May 2003 07:53:39 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols Message-ID: <3EB7CC73.9C61C27E@mindspring.com> References: <20030501182820.GA53641@madman.celabo.org> <XFMail.20030501144502.jhb@FreeBSD.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: > What if I define my own printf() that doesn't fully implement all the > functionality of the FreeBSD printf()? It works meets all the requirements > for my code (and maybe even runs correctly elsewhere) but doesn't work > on FreeBSD because a library internal call (hypothetically) relies on > functionality that I don't need. This is actually a library implementation problem, related to incestuous implementation of library calls. If another library function doesn't use e.g. strlcpy() internally, then it will not be effected by an application replacing strlcpy(). It's only when a library function depends on another library function, rather than itself, that it's at risk for this type of failure. Perhaps instead of asking how to prevent symbol replacement, one should be asking how to get rid of incestuous functions in the library implementation for standard library functions. No, I do not expect "_fmt" (or whatever) to go away from common code in printf/sprintf/whatever. But I do expect it to be "_fmt" instead of "fmt", i.e. in implementation space, rather than in the symbol space legal for users to use. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EB7CC73.9C61C27E>