Re: [PATCH] Set behavior of sprintf-like functions with overlapping source and destination

[Paul Eggert <eggert at cs dot ucla dot edu>]

Jonathan Nieder wrote:

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

How about if we comment out the test, or enable it only if some weird macro is 
already defined?

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

It is a special case, indeed.

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

I'm afraid it sounds confusing, as GLIBC_2.29 wouldn't be the default for glibc 
2.29 when it's released. Perhaps the symbol should be GLIBC_UNSTABLE instead? 
But even then, I don't see why users would use the new version before the 
default was switched, so if there are issues we won't find them any more gently 
with this approach.