cvs commit: src/lib/libc/gen check_utility_compat.c confstr.c un-namespace.hgethostbydns.c getnameinfo.c hesiod.c ...

[Daniel Eischen]

On Wed, 30 Apr 2003, Paul Richards wrote:

> On Tue, Apr 29, 2003 at 11:26:47PM -0700, Kris Kennaway wrote:
> > On Wed, Apr 30, 2003 at 12:33:03AM -0400, W. Josephson wrote:
> > > On Wed, Apr 30, 2003 at 12:27:22AM -0400, Daniel Eischen wrote:
> > > > Why can't you still do this?  You just have to know the real
> > > > name of the function you want to override.  Is malloc any
> > > > different than _malloc, so that you can't supply your own
> > > > with the correct symbol?
> > > 
> > > It is just one more thing to hack around on
> > > every platform.  I still don't understand
> > > why the urge to make things more complicated
> > > for the sake of admittedly broken software.
> > > Why not just fix the bug at its source rather
> > > than making life more difficult for stuff that
> > > is written correctly?
> > 
> > Because the source is not always available.  Fortunately, for qpopper
> > it is, but as Jacques stated in another message there is a chance that
> > other binary applications also do this.
> 
> Hiding our libc implementation is the wrong approach here. I think the
> strlcpy hiding should be taken out.

There's another problem here.  We *should* be hiding symbols that become
exposed to application namespace (through no fault of the application) if
they are not part of a relevent spec.  strlcpy doesn't seem to be part
of POSIX; is there some other standard to which it belongs?  If not, and
our libc is using them internally or they are becoming unexpectedly
exposed some other way, then they need to be hidden.

-- 
Dan Eischen