This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: asprintf() issue


On Wed, May 20, 2015 at 08:29:59AM +0200, Florian Weimer wrote:
> On 05/20/2015 06:30 AM, Carlos O'Donell wrote:
> 
> >> 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).
> > 
> > I disagree that the compat symbol is not worth the cost.
> > 
> > Such a change stands to break binaries that were previously working, and in 
> > glibc we stand by our community commitment not to break user code.
> 
> Sorry, I've now realized what I wrote was unclear.  I meant that if we
> make such a minor change (without clear improvement for developers, in
> my opinion), and it needs a compat symbol (which is the case here, I
> agree), then making the change may not be worth it.

I think the issue with asprintf not setting *ptr to NULL is not of that
importance as back in 2001 when my proposal was dreppered down.  Thanks to
warn_unused_result attribute, most of software (where checking return code
of memory allocating functions is considered relevant) has been fixed to
check asprintf return code instead of relying upon *ptr being set to NULL
on error.

Some distributions, Owl and ALT Linux included, are patching glibc since
2001 to make asprintf set *ptr to NULL on error.  It's quite a period of
time to stumble upon a piece of code that relies upon current mainline
glibc behaviour of not changing *ptr on error, and we haven't heard of
such issues.  It is extremely unlikely that such code ever existed.
That is, I don't see any risk of breaking user code by correcting asprintf
behaviour without introduction of a compat symbol.

Said that, I don't object to introduction of a compat symbol for asprintf
if there is a general consensus that any user visible change requires
introduction of a compat symbol.  Those distributions that adopted my
patch for asprintf or developed an equivalent change will have to support
a patch removing this compat symbol, but it shouldn't be an issue as
they must be prepared to support their edition of asprintf anyway.


-- 
ldv

Attachment: pgp2FmDQQD825.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]