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: Fri, 29 May 2015 11:00:29 -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> <555C0DDF dot 1090408 at redhat dot com> <555C29E7 dot 8090403 at redhat dot com> <CANSoFxtYs0QdsMAg7bpZRwm1dJ8F5g3ZjXZCEEp7wr0qRDbf6g at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1505291045300 dot 2439 at digraph dot polyomino dot org dot uk>
On Fri, May 29, 2015 at 5:47 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> > What are the next steps on this asprintf() issue?
>
> If a long discussion with various different views dies down, the next step
> is to post a careful analysis of that discussion to help the community in
> reaching consensus, or to help the community see what the consensus is
> that was reached.
OK here goes...
First question: should the new, specified behavior be set to NULL or
leave unmodified? The general agreement is to set to NULL: consistent
with BSD, what people are already patching glibc to do, more
developer-friendly, better at detecting bugs, etc.
Second question: what should specification/man page say? General
agreement that we should document both the new behavior, the previous
behavior, and the version in which the change occurred.
Next question: whether to just change the behavior or create a symbol
alias. If the latter, there were two options:
- option (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)
- option (c): have a new symbol version with the old version
not changing *ptr on error
Initially most agreed creating an alias using option (c). Then Florian
said creating an alias was not worth the trouble, there was some
discussion, and then Florian came around saying "If that's the
emerging consensus, it's something with which I can agree."
So... I think we now have consensus for option (c).
Carlos also pointed out we should add a test case that tests the
ENOMEM failure case.
Does that summary sound right?
-Archie
--
Archie L. Cobbs