Your byte implementation is unsafe under optimisation on GCC and clang

[ned14]

The C++ 20 standard defines std::byte* to have the same may-alias properties as char*.

Your byte implementation therefore needs to be marked up with __attribute__((__may_alias__)) on GCC and clang compilers to tell the compiler that it must not assume that byte* cannot alias a pointer to a different type.

[neilmacintosh]

Sounds pretty reasonable to me. I'm guessing that's only necessary if someone is running without the -fno-strict-aliasing switch? Does anyone want to put together a PR?

[xaxxon]

only necessary if someone is running without the -fno-strict-aliasing switch

What was the point of calling that out?

[martinmoene]

@xaxxon See the disscussion at PR #390.

[xaxxon]

a note to the readme, recommending to use the -fno-strict-aliasing flag on gcc and clang.

Just to be clear, we're not suggesting anyone prefer to flags to enable extensions to use non-standard c++, right?

[martinmoene]

It's C++17 behaviour, see

• N4659 sec 6.10, p8.8, page 84
• std::byte on cppreference.com
• Has a std::byte pointer the same aliasing implications as char*? on StackOverflow.

[xaxxon]

-fno-strict-aliasing is not c++17 behavior as far as I can tell. no-strict-aliasing treats everything as if it were a char* from what I can see.

[martinmoene]

Ah, had the impression you were referring to __attribute__((__may_alias__)).

[ned14]

Strict aliasing has been on by default in GCC for a very long time at -O2 and above. clang gained the same maybe four or five years ago. MSVC once had opt-in strict aliasing a long time ago, but they removed it and its magic compiler options.

In any case, on GCC and clang, __attribute__((__may_alias__)) needs to be applied to the byte type, else the compiler will hard assume it will never alias unrelated types, which is exactly what byte is for!

[jack17529]

@neilmacintosh I think there is some issue regarding your Facebook link on your profile.
I am sorry but this nowhere related to the issue.
I too wanted to talk privately regarding GSL

[neilmacintosh]

@xaxxon I was simply asking a question, not "calling anything out". I wanted to understand the situations that would/wouldn't expose people to the problem that was being reported.

Both -fno-strict-aliasing and __attribute__ are language extensions as far as I am aware. Both are options for getting something like the behavior of C++17 std::byte if you don't yet have native support for it in your toolchain. So far, the attribute sounds like the path with less side-effects.

@jack17529 If you would like to contact me directly, I can be reached at neilmac@fb.com.

[StephanDollberg]

Have ported @martinmoene's patch and opened a PR.