Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change

["Zack Weinberg" <zack@owlfolio.org>]

On Tue, Dec 13, 2022, at 2:25 PM, Noah Goldstein via Libc-alpha wrote:
> On Tue, Dec 13, 2022 at 11:13 AM Narayanan Iyer <nars@yottadb.com> wrote:
>> Thank you for acknowledging that it is a bug.
> I'm not sure this is a bug, I'm just saying to avoid this behavior you can
> make that change.
>
> I think we all agree supporting a correct non-atomic memcmp when the values
> in memory can change during execution is not reasonable.
> I think SIG11 is not a great outcome (of the many possible behaviors when its
> incorrect), but am not sure it's worth fixing.

I think it would be reasonable for glibc to make the following weaker guarantee:
for any call `memcmp(a, b, n)`, if the data pointed to by `a` and/or `b` is being
concurrently modified, the return value is unspecified but *not* indeterminate.
Also, memcmp will never access memory outside the bounds [a, a+n) and [b, b+n),
no matter what.

This would, I believe, be sufficient to prevent a crash under the conditions
described by Narayanan Iyer.

zw