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

[Florian Weimer]

* Zack Weinberg:

>> The sprintf change clearly is in category (2).  However, there's a
>> mitigation circumstance: Distributions already build with
>> _FORTIFY_SOURCE (at least they try to), so they are largely exposed to
>> the new behavior.  So I'd expect that in this particular case, the
>> recompilation problem would largely affect unpackaged, in-house
>> software.  Maybe this makes the change more acceptable and could
>> actually justify introducing a symbol version in this case?
>
> It seems to me it's the other way around: distribution-packaged
> software is more likely to receive fixes for this type of problem than
> unpackaged in-house stuff is.

On common code paths, yes, but the same applies to in-house code.
What I tried to say is that the distribution fixes have already
happened due to the impact of -D_FORTIFY_SOURCE=2 by default and
hopefully have been upstreamed by now.  (This may have given us the
delay that Jonathan was suggesting.)  As a result, we wouldn't punish
free software over proprietary software in this case.  Sorry if I
didn't explain my line of reasoning clearly enough.