char can be unsigned.

char can be unsigned.

So if char happens to have unsigned char as its underlying type because of an implementation-defined choice, then std::bit_cast is allowed to produce an indeterminate value?

If this is really the intended behavior, then I think this deserves a note at least, because it is really obscure.

The way that [basic.fundamental] p7 is phrased, char cannot be unsigned char, but it can have an unsigned underlying type. This puts into question whether char ever is unsigned.

Furthermore (and this is leaving the realm of editorial issues), in all other circumstances known to me, "unsigned" char does not behave specially, only unsigned char does. See [intro.object] p13 for instance. This behavior of "unsigned" char being special breaks the norm, and is very surprising.

I've looked into it, and the issue which introduced the wording is https://cplusplus.github.io/CWG/issues/2482.html.

This issue uses the term byte-like type, which normally refers to unsigned char and std::byte, but [basic.indet] also uses unsigned ordinary character type. If there is any issue, and there probably isn't, then it starts with [basic.indet].

Related #5070

Ideally, [basic.indet] should be simultaneously changed, which fixes #5070. However, a CWG issue seems needed for this.

Ideally, [basic.indet] should be simultaneously changed, which fixes #5070. However, a CWG issue seems needed for this.

You're right, and after looking further into it, I've opened cplusplus/CWG#403

I don't think there's anything for us to do here editorially.