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@xxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
