`vector_algorithms.cpp`: undefined behavior

[AlexGuteniev]

We have some intentional unaligned access in vector_algorithms.cpp. Some occurrences are marked:

STL/stl/src/vector_algorithms.cpp

Lines 114 to 141 in 48db51b

	#if defined(_M_X64) // NOTE: UNALIGNED MEMORY ACCESSES
	constexpr size_t _Mask_8 = ~((static_cast<size_t>(1) << 3) - 1);
	if (_Byte_length(_First1, _Last1) >= 8) {
	const void* _Stop_at = _First1;
	_Advance_bytes(_Stop_at, _Byte_length(_First1, _Last1) & _Mask_8);
	do {
	const unsigned long long _Left = *static_cast<unsigned long long*>(_First1);
	const unsigned long long _Right = *static_cast<unsigned long long*>(_First2);
	*static_cast<unsigned long long*>(_First1) = _Right;
	*static_cast<unsigned long long*>(_First2) = _Left;
	_Advance_bytes(_First1, 8);
	_Advance_bytes(_First2, 8);
	} while (_First1 != _Stop_at);
	}
	#elif defined(_M_IX86) // NOTE: UNALIGNED MEMORY ACCESSES
	constexpr size_t _Mask_4 = ~((static_cast<size_t>(1) << 2) - 1);
	if (_Byte_length(_First1, _Last1) >= 4) {
	const void* _Stop_at = _First1;
	_Advance_bytes(_Stop_at, _Byte_length(_First1, _Last1) & _Mask_4);
	do {
	const unsigned long _Left = *static_cast<unsigned long*>(_First1);
	const unsigned long _Right = *static_cast<unsigned long*>(_First2);
	*static_cast<unsigned long*>(_First1) = _Right;
	*static_cast<unsigned long*>(_First2) = _Left;
	_Advance_bytes(_First1, 4);
	_Advance_bytes(_First2, 4);
	} while (_First1 != _Stop_at);
	}

There may be some unmarked occurrences as well.

I can think of a few fixing that

1. memcpy. The usual way, but it makes debug codegen slightly worse. #pragma intrinsic can partly mitigate debug codegen worsening.
2. __builtin_bit_cast. Perfect codegen, ugly construct:

   unsigned long long cast(void* p) {
      return __builtin_bit_cast(unsigned long long, *reinterpret_cast<unsigned char(*)[8]>(p));
   }
   

There's a bug reported by A. Jiang (@frederick-vs-ja) as DevCom-10974125, now Fixed - Pending Release. Workaround is to save the reinterpret_cast result to a variable.

3. __builtin_bit_cast wrappers std::_Bit_cast or std::bit_cast. Same as the previous, plus function call in debug. Avoids the bug.

The memcpy approach has already been used in some more recent parts, so if we prefer other approach, we may want to revisit that as well:

STL/stl/src/vector_algorithms.cpp

Line 6927 in 48db51b

memcpy(&_Val, _Src, sizeof(_Val));

[frederick-vs-ja]

2. __builtin_bit_cast. Perfect codegen, ugly construct:

unsigned long long cast(void* p) {
   return __builtin_bit_cast(unsigned long long, reinterpret_cast<unsigned char(&)[8]>(p));
}

Looks weird. Did you mean __builtin_bit_cast(unsigned long long, *reinterpret_cast<unsigned char(*)[8]>(p))?

Pedantically speaking, UB is still (possible?) present in this way, but this is fine as long as mis-optimization doesn't occur. We're already doing this in formatting mechanism.

STL/stl/inc/__msvc_ranges_tuple_formatter.hpp

Lines 643 to 647 in 48db51b

	template <class _Ty>
	_NODISCARD static auto _Get_value_from_memory(const unsigned char* const _Val) noexcept {
	auto& _Temp = *reinterpret_cast<const unsigned char (*)[sizeof(_Ty)]>(_Val);
	return _STD bit_cast<_Ty>(_Temp);
	}

[AlexGuteniev]

Looks weird. Did you mean __builtin_bit_cast(unsigned long long, *reinterpret_cast<unsigned char(*)[8]>(p))?

Yes.

Pedantically speaking, UB is still present in this way

How?

[frederick-vs-ja]

Pedantically speaking, UB is still present in this way

How?

[dcl.ref]/6 indicates that mistyped reference binding (e.g. binding a unsigned char (&)[N] to some area where there's no such an array) is UB. Although I'm not sure whether there's reference binding in a raw __builtin_bit_cast call (not bit_cast/_Bit_cast).

[AlexGuteniev]

Direct builtin use seem to go wrong: https://godbolt.org/z/E5WzG1c1b

[frederick-vs-ja]

The following seemingly works (https://godbolt.org/z/5Yb5Ef5da), which is strange...

unsigned long long cast1x(void* p) {
    auto pp = reinterpret_cast<unsigned char(*)[8]>(p);
    return __builtin_bit_cast(unsigned long long, *pp);
}

[frederick-vs-ja]

Reported DevCom-10974125. Seems already fixed in an unreleased version a newer VS 2026 version.

[StephanTLavavej]

I'd prefer to just use the memcpy technique. The debug codegen impact is acceptable.