This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Set behavior of sprintf-like functions with overlapping source and destination
On Wed, Dec 26, 2018 at 8:19 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> On 27/12/18 3:52 AM, Paul Eggert wrote:
> >> 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.
>
> We should not retain compatible behaviour for building, only for linking
> like we normally do. The symbol versioning patch won't get backported
> (since it is an ABI event) to older distributions and as long as it is
> alongside gcc8+ (I tested 8, the warning might have been introduced
> earlier) there is an adequate warning that tells users their houses may
> burn down if they depend on this behaviour. Or something like that.
Despite having written the patch that broke the old behavior, I think
this is much too aggressive. The fact that we almost immediately
discovered breakage after the patch landed means there are probably a
whole lot of programs out there relying on it, and I don't think it's
safe to assume people will pay attention to warnings _or_ read
documentation. Witness how people are _still_ complaining about the
memcpy change.
I'm inclined to say that this degree of freedom is now frozen and we
need to accept that the old behavior has become a supported GNU
extension and we should document it as such, test for it, etc. Not a
good extension, but one we are stuck with. Failing that, I think we
need to preserve the old behavior for at least one more full release
and we need to announce as loudly and widely as possible that we are
changing it. If we do change it, we should also make sure that the
new behavior is well-defined and tested for all cases of overlapping
buffers, and what the new behavior is must be documented, and we need
to stick to it.
zw