On Tue, Jan 29, 2013 at 10:39:21AM +0100, Florian Weimer wrote:
> On 01/28/2013 06:31 PM, Bill Nottingham wrote:
> >Florian Weimer (fwei...@redhat.com) said:
> >>See <http://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv>
> >>for code snippets to implement in the change in a
> >>backwards-compatible fashion. Unfortunately, glibc upstream
> >>insistent on renaming before making the symbol official.
> >
> >I'm a little confused by the 'unfortunately' here - if apps are using a
> >private symbol, they should expect that they may need to change later.
>
> Precisely because it's in the private namespace, glibc could just
> have documented the existing __secure_getenv symbol. It's not that
> there aren't any public functions starting with __. But this was
> rejected by upstream, and now we have the __secure_getenv
> compatibility symbol (not usable for fresh linking), secure_getenv,
> and __libc_secure_getenv for internal glibc use (but which is still
> public for technical reasons).
A @@GLIBC_PRIVATE symbol is not public.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
