Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 06 May 2003 22:38:30 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        "Jacques A. Vidrine" <nectar@FreeBSD.org>
Cc:        freebsd-arch@FreeBSD.org
Subject:   Re: `Hiding' libc symbols
Message-ID:  <3EB89BD6.4F1C0807@mindspring.com>
References:  <Pine.BSF.4.21.0305011046140.73226-100000@InterJet.elischer.org> <XFMail.20030501140549.jhb@FreeBSD.org> <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506175557.GE79167@madman.celabo.org>

next in thread | previous in thread | raw e-mail | index | archive | help
"Jacques A. Vidrine" wrote:
> > > Do you also want to `fix' the other ports that define their own strlcpy?
> >
> > Ports have maintainers.  Please create a PR for them.
> 
> But gee, the problem is that the ports themselves are not really
> in error, unless one is a standards fascist that believes that an
> application can never define any function that might be in some
> standard's namespace.

I'm a standards faciest, though I'm usually pretty lenient
about it, unless it comes to obvious bugs like code not using
pthreads_mutex'es where required by the standard.

And I think the problem can happen, even though the ports may
not be in error.

Consider: the linker sees symbols defined in libc, even if
the compiler doesn't because of all the namespace voodoo
having been done precisely correctly in the application.

There are also a number of libc functions which are defined
by a newer standard but not an older one, which are used
internally to implement functions defined in both the older
and newer standards, such that if the port is compliant with
the older standard, has it's namespace ducks all in a row,
and carries around it's own copy of the newer function, it
will cause functions in the standard with which it complies
to fail.

In other words, just because the compiler can't see it, does
not mean the linker won't.


It's probably impossible to resolve this completely, without
more linker-foo and compiler-foo than I'm willing to contemplate
to make the linker aware of the standards used by the compiler.

God help you, if you have a program that depends on a third
party library that depends on a system library...

-- Terry



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EB89BD6.4F1C0807>