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 Thu, 20 Dec 2018, Paul Eggert wrote:
>Dumb question: if fortification is enabled, why can't sprintf-like
>functions report an error when the source and destination overlap? The
>point of fortification is to catch and report undefined behavior when
>it's easy, as is the case here.
With fortification enabled, they still do. This change is more about the
non-fortified case...
Before commit ID 4e2f43f842ef, non-fortified sprintf and vsprintf did
*not*:
1. report buffer overflows and terminate the program;
2. overwrite overlapping buffers.
But since commit ID 4e2f43f842ef, they do (I haven't noticed these changes
when working on that patch, now they are being questioned here:
https://sourceware.org/ml/libc-alpha/2018-12/msg00634.html and
https://sourceware.org/ml/libc-alpha/2018-12/msg00839.html).
This new patch is about reverting these two items for the non-fortified
case (maybe they should be considered separately).
>> /* Test the sprintf (buf, "%s", buf) does not override buf.
>
>I'm leery of adding this test case, as it tests undefined behavior that
>the glibc manual does not document as an extension (and it shouldn't be
>documented either).
>
>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...