This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: asprintf() issue
- From: Archie Cobbs <archie dot cobbs at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha at sourceware dot org, Michael Kerrisk-manpages <mtk dot manpages at gmail dot com>
- Date: Mon, 18 May 2015 09:12:21 -0500
- 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> <5559C31D dot 5070400 at redhat dot com> <CANSoFxueAj7HapmHe3cFjK+1KEo-JoyoxWWSnaXhVwMyxGP8Ag at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1505181357320 dot 20209 at digraph dot polyomino dot org dot uk>
On Mon, May 18, 2015 at 8:59 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Mon, 18 May 2015, Archie Cobbs wrote:
>
>> On Mon, May 18, 2015 at 5:46 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> > > IMO we should be conservative and do (c), and document in NEWS, Release wiki
>> > > page, and hopefully the manual.
>> >
>> > I don't think this is worth the cost. (Even such little changes add up
>> > and eventually impact linking time and code size.) It does not even fix
>> > a bug, and application code can easily set *ptr to NULL before calling
>> > asprintf, to get uniform behavior across all known implementations (if
>> > that simplifies application code).
>>
>> This makes sense to me as well. What about this then:
>
> Even if you don't do (c) old symbol version behaves as now, are you sure
> about doing (a) no new symbol version, rather than (b) new symbol version,
> both are aliases, so new binaries won't run with old glibc?
Yes I also agree (b) would be safer... but being new here I don't know
how to create symbol 'aliases' so either someone else will have to do
it (or explain to me how :)
Thanks,
-Archie
--
Archie L. Cobbs