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

[Paul Richards]

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.

Your example of binary only applications actually shows exactly why this
approach is wrong since if the application deliberately tries to
override the libc version then it won't work.

If it's a bug in the application then it's a bug in the application and
either that gets fixed in the source or you complain to the vendor.Messing
with the exported symbols from libc doesn't seem like the right solution
to me.

-- 
Paul Richards