This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: asprintf() issue
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Archie Cobbs <archie dot cobbs at gmail dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, <libc-alpha at sourceware dot org>, Michael Kerrisk-manpages <mtk dot manpages at gmail dot com>
- Date: Wed, 13 May 2015 16:14:01 +0000
- 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>
On Wed, 13 May 2015, Archie Cobbs wrote:
> On Tue, May 12, 2015 at 10:11 AM, Florian Weimer <fweimer@redhat.com> wrote:
> > To me, this implies the original value is preserved. We can add this to
> > the documentation if that makes everyone happy.
>
> Here's a proposed patch:
>
> manual/stdio.texi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/manual/stdio.texi b/manual/stdio.texi
> index e407170..bf7cffe 100644
> --- a/manual/stdio.texi
> +++ b/manual/stdio.texi
> @@ -2551,6 +2551,8 @@ The return value is the number of characters
> allocated for the buffer, or
> less than zero if an error occurred. Usually this means that the buffer
> could not be allocated.
>
> +If an error occurs, the contents of *@var{ptr} are not modified.
It's not clear to me that we want to guarantee this as an API. (Though
the existence of code relying on it would indicate that if we changed it,
we should also change the symbol version and keep a version that doesn't
modify it at the old symbol version. And as I understand that bug report,
the code in question would work just as well if glibc changed to set it to
NULL, which was previously requested in
<https://sourceware.org/ml/libc-alpha/2001-12/msg00021.html>. I don't see
any good reason to do something other than leaving it unchanged or setting
it to NULL, however.)
Does anyone know of implementations that do something other than leaving
the value unchanged or setting it to NULL? The external specifications in
question are LSB and TR 24731-2:2010 (which defers to LSB), and they seem
to be silent on this issue.
--
Joseph S. Myers
joseph@codesourcery.com