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

[Carlos O'Donell]

On 12/13/22 15:56, Zack Weinberg via Libc-alpha wrote:
> 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.

I disagree strongly.

These are advanced lockless techniques.

They should be hidden behind new APIs that provide the required guarantees.
 
> This would, I believe, be sufficient to prevent a crash under the conditions
> described by Narayanan Iyer.

I would want to see compiler and langauge authors agree to such changes.

-- 
Cheers,
Carlos.