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 (fweimer(a)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