<bitset>: streaming operator >> does not use character traits

[AlexGuteniev]

_Char is directly compared against _Elem0 and _Elem1

STL/stl/inc/bitset

Lines 589 to 600 in 73b5791

	if (_Tr::eq_int_type(_Tr::eof(), _Meta)) { // end of file, quit
	_State |= _Istr_t::eofbit;
	break;
	} else if ((_Char = _Tr::to_char_type(_Meta)) != _Elem0 && _Char != _Elem1) {
	break; // invalid element
	} else if (_Str.max_size() <= _Str.size()) { // no room in string, give up (unlikely)
	_State |= _Istr_t::failbit;
	break;
	} else { // valid, append '0' or '1'
	_Str.push_back('0' + (_Char == _Elem1));
	_Changed = true;
	}

[AlexGuteniev]

If we want test coverage, we could wait for #4951 and then share significant test part.

[StephanTLavavej]

We checked, and fortunately bitset's constructor properly implements WG21-N4988 [bitset.cons]/6 "The function uses traits::eq to compare the character values." (here and on other lines):

STL/stl/inc/bitset

Line 121 in a26f4ad

if (!_Traits::eq(_Elem1, _Ch) && !_Traits::eq(_Elem0, _Ch)) {

So the problem is limited to the streaming operator. We'll grumble a bit that [bitset.operators]/5.3 "the next input character is neither is.widen('0') nor is.widen('1') (in which case the input character is not extracted)" is vague about how "neither" is determined, and this probably deserves an LWG issue, but the intent seems to be clear enough.