This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 27/12/18 3:52 AM, Paul Eggert wrote:
I wonder if something like the following would be too complex:

  1. Introduce GLIBC_2.29 printf that does *not* support this undefined
     behavior.  Use __asm__(".symver [...]@@GLIBC_2.0") to ensure we
     still default to the GLIBC_2.0 version even when building new
     programs.

  2. After a critical mass of users are using glibc 2.29 or newer (e.g.
     after a year), switch the default version to GLIBC_2.29.

What do you think?

I'm afraid it sounds confusing, as GLIBC_2.29 wouldn't be the default for glibc 2.29 when it's released. Perhaps the symbol should be GLIBC_UNSTABLE instead? But even then, I don't see why users would use the new version before the default was switched, so if there are issues we won't find them any more gently with this approach.

We should not retain compatible behaviour for building, only for linking like we normally do. The symbol versioning patch won't get backported (since it is an ABI event) to older distributions and as long as it is alongside gcc8+ (I tested 8, the warning might have been introduced earlier) there is an adequate warning that tells users their houses may burn down if they depend on this behaviour. Or something like that.

The risk is not completely gone though and there may be environments (gcc5 for example) where there is no warning. These would be custom built environments though and I suppose we can depend on these devs to read the manpage more carefully. Or maybe add more code in the headers to link against the compat *printf if an older compiler is detected? It's debatable if all of this is necessary for undefined behaviour...

In any case, this doesn't look like something that'll be done within this week, so I propose we add this compatibility change in now (without the UB test) in the interest of not breaking things and then add versioning to only retain backward compatible behaviour for GLIBC_2.0 printf after discussing at length how much breakage we can stand. Maybe also get friends at LWN to write about how sprintf using aliased buffers is asking for trouble.

With this action plan we don't really need to test the undefined behaviour since we don't intend to retain it except in the compat case, just flip the switch in the ub-chk test later so that it always does the check instead of only under _FORTIFY_SOURCE.

Siddhesh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]