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

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

On Fri, Dec 30, 2022, at 1:02 PM, Joseph Myers wrote:
> I also think it should be OK for strcmp to SEGV if a NUL terminator
> byte in either string at the time strlen is called, or at any time
> during its execution, ceases at any point during the execution of
> strlen to be a NUL byte (even if there is an earlier or later NUL
> already present at the time the terminator byte is changed).  (There
> is a reasonable case for avoiding a SEGV when the contents of the
> strings change during execution, as long as any byte that is the NUL
> terminator byte at any point during execution of the call never ceases
> to be a NUL byte during execution of that call - an earlier NUL might
> be added, however.)

Coming back to this ages later, I'm not sure how this differs from what
I said about the oracle for strlen... Imagine we have a hardware
debugger that can freeze execution of the entire computer at the moment
the call instruction for strcmp is invoked, perform strlen() on both
strings passed to strcmp, and then resume execution.  Call the string
lengths measured by this hypothetical debugger the "original" string
lengths.  What I was trying to communicate is that any concurrent
modification to the strings that *changes either string's length from
its original* should still permit constrained-unpredictable behavior by
the implementation of strcmp. It seems to me that this is the same as
talking about insertion or deletion of NULs within the bounds of the
original string lengths.

zw