This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: asprintf() issue
- From: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: mtk dot manpages at gmail dot com, Archie Cobbs <archie dot cobbs at gmail dot com>, Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Thu, 14 May 2015 15:42:10 +0200
- Subject: Re: asprintf() issue
- Authentication-results: sourceware.org; auth=none
- References: <CANSoFxt-cdc-+C4u-rTENMtY4X9RpRSuv+axDswSPxbDgag8_Q at mail dot gmail dot com> <55520F8F dot 9020308 at redhat dot com> <CANSoFxvac6_uBgwzWm5q6U+GcWzzKtDtDP0BVvE4eL08zXHs5Q at mail dot gmail dot com> <5552183C dot 2070809 at redhat dot com> <CANSoFxv7uO2Niq+wVKsC9xoDYuNgqHFxJnLrkgNqfKpFwzde=Q at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1505131601320 dot 30846 at digraph dot polyomino dot org dot uk> <555385F4 dot 5000409 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1505131722190 dot 30846 at digraph dot polyomino dot org dot uk> <555432DE dot 1020608 at redhat dot com>
On 05/14/2015 07:30 AM, Carlos O'Donell wrote:
> On 05/13/2015 01:24 PM, Joseph Myers wrote:
>> On Wed, 13 May 2015, Carlos O'Donell wrote:
>>
>>> My preference is that we set it to NULL. This will aid in debugging as any
>>> dereferences to NULL will immediately trap. Leaving the value unchanged
>>> could result in further manipulation of an invalid memory location and
>>> program corruption.
>>
>> If we do this, do we then want to
>>
>> (a) not have a new symbol version; or
>>
>> (b) have a new symbol version with the old version being an alias of the
>> new (so that new binaries that may rely on it being set to NULL don't run
>> with old glibc - similar to the symbol versioning of <fenv.h> functions
>> whose return type changed from void to int in C99 TC1, for example); or
>>
>> (c) have a new symbol version with the old version not changing *ptr on
>> error?
>
> IMO we should be conservative and do (c), and document in NEWS, Release wiki
> page, and hopefully the manual.
>
> There are arguments for (b) given that the manual page says the behaviour
> is undefined,
I don't consider the argument strong though. I imagine it
is what Andries made up (lacking further information) on the
day he wrote the page.
> but I do not believe this will result in the best user
> experience.
>
> Other opinions?
Setting the pointer to NULL + (c) sounds good to me.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/