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: [PATCH] Set behavior of sprintf-like functions with overlapping source and destination


Paul Eggert wrote:
> Siddhesh Poyarekar wrote:
>> On 21/12/18 3:47 AM, Paul Eggert wrote:

>>> Traditionally we didn't worry about breaking code like PughUtils.c's
>>> 'sprintf(mess,"%s %d",mess,...)' under the principle that such code
>>> was already broken. Why depart from that tradition here?
>>
>> Is the disagreement here only about testing UB or also about retaining
>> old behaviour in case of UB?
>
> Primarily the former. I don't want us to test for and/or guarantee support
> for this particular implementation of UB. (Although I'm not happy about the
> extra code inserted into every printf call to deal with this situation, it's
> not like printf is particularly fast now....)

Can we keep the test and just include a (source) comment describing the
lack of support behind it?

It feels odd to bend over backwards to support a behavior on one hand,
while not having a test for it on the other.

>> If it's just the former then we could make forward progress by just
>> removing the UB test case and just keeping the ub-chk test case.
>>
>> It may not be too hard for the compiler to see this undefined behaviour
>> and warn about it either, at least in some trivial cases...
>
> Yes, that'd be good.

Learning from the GLIBC_2.14 memcpy, I wonder what our best option is.
I wonder if something like the following would be too complex:

 1. Introduce GLIBC_2.29 printf that does *not* support this undefined
    behavior.  Use __asm__(".symver [...]@@GLIBC_2.0") to ensure we
    still default to the GLIBC_2.0 version even when building new
    programs.

 2. After a critical mass of users are using glibc 2.29 or newer (e.g.
    after a year), switch the default version to GLIBC_2.29.

What do you think?

Thanks,
Jonathan


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