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
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Gabriel F. T. Gomes" <gabriel at inconstante dot eti dot br>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, <libc-alpha at sourceware dot org>
- Date: Fri, 21 Dec 2018 01:24:09 +0000
- Subject: Re: [PATCH] Set behavior of sprintf-like functions with overlapping source and destination
- References: <20181220215409.8971-1-gabriel@inconstante.eti.br> <fd68b440-14ce-dd14-fd80-20c80e097e20@cs.ucla.edu> <20181220232115.37d8ad2b@tereshkova>
On Thu, 20 Dec 2018, Gabriel F. T. Gomes 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?
>
> I don't know how to answer that... I'm sort of a rookie, and I wasn't
> here to witness past, similar changes and what was the fallout. Maybe
> other people have better, backed opinions about it...
We have the example of x86_64 memcpy (where a GLIBC_2.14 version was added
to avoid breaking old *binaries* expecting it to have memmove semantics,
but in that case breaking *sources* expecting overlapping copies to work
was considered fine).
--
Joseph S. Myers
joseph@codesourcery.com