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
* 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.