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

[Zack Weinberg <zack@owlfolio.org>]

Carlos O'Donell <carlos@redhat.com> writes:

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

I’m really surprised to hear you say that.  To me this is a natural
guarantee for memcmp — in fact, for *all* of the mem* functions — to
make, to the point where my reaction was *of course* this is our bug!

> These are advanced lockless techniques.
> They should be hidden behind new APIs that provide the required guarantees.

That the application was doing “advanced lockless techniques” is, to me,
not relevant in the slightest.  The important thing to me is that the
memory regions `memcmp` is allowed to access are wholly specified by the
mathematical values of its three arguments, and *not* by the data
pointed to by the first two arguments.  Nothing any other thread does
can change the fact that memcmp has no business touching bytes at
addresses outside [a, a+n) and [b, b+n).

Why do you think it is important for the C library to have latitude to
break that aspect of the mem* functions’ API contract?  Even if only
under exotic circumstances?

zw