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

[Siddhesh Poyarekar <siddhesh at gotplt dot org>]

On 21/12/18 3:47 AM, 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.
>
> > /* 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?

Is the disagreement here only about testing UB or also about retaining 
old behaviour in case of UB?  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...

Siddhesh