Fix undefined behavior in regex_macros

[Amanieu]

The value read in contains may be uninitialized, and using such a value is undefined behavior. In particular with LLVM, where s is undef and can return a different value each time it is read. The solution is to use a volatile load to ensure we already get a real value, not an undef.

[Amanieu]

Note that this is currently blocked on rust-lang/rust#32804

[BurntSushi]

@Amanieu Hmm, are you sure? The whole point of the sparse set optimization is that it never actually reads from uninitialized memory. See: http://research.swtch.com/sparse

[Amanieu]

Actually it does read from uninitialized memory (sparse[i]):

If i is not in the set, then it doesn't matter what sparse[i] is set to: either sparse[i] will be bigger than n or it will point at a value in dense that doesn't point back at it.

[BurntSushi]

@Amanieu ah, I see, yeah you're right. (I'd also be fine removing the optimization altogether.)

[Amanieu]

Removing the optimization entirely is also an option, I think either way is fine.

[alexcrichton]

From an LLVM point of view, I believe it's correct that it's not undefined behavior to read undefined memory, it just returns undef. I also think that it's not undefined behavior to use that undef value, it just propagates. For example if you add an undef value to something else, the returned value is always undef.

The unefined behavior, however, is when you start doing things like branching and such. For example here if s can be undefined then the comparison < can be optimized away (as can the bounds checks in the array access), which then will cause undefined behavior.

(nice catch regardless!)

[Amanieu]

This should work now that read_volatile has been stabilized in the latest nightly.

[BurntSushi]

Hmm, just waiting on the Windows CI to go through.

[BurntSushi]

Awesome, thank you! :-)