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] |
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] |