<xstring>: resize_and_overwrite generates warning C4018 when Operation returns int

[PowerGamer1]

The bug description
According to C++23 draft the Operation op of std::string member function resize_and_overwrite does not have to return size_t, it can also return, for ex., int (https://eel.is/c++draft/string.capacity#8):

[21.3.3.5] Capacity [string.capacity]
...
Mandates: OP has an integer-like type ([iterator.concept.winc]).

When op returns int the compiler produces "warning C4018: '<=': signed/unsigned mismatch" inside STL implementation code that performs _STL_VERIFY check on op return value under debug build.

Command-line test case

#include <string>
int main() {
	std::string s;
	s.resize_and_overwrite(1, [](char* buffer, size_t) {
		*buffer = 'x';
		int i = 1;
		return i;
	});
}

Compile for debug, x86 platform and with /std:c++latest, /W3.

Expected behavior
No warning produced by the compiler.

STL version
STL version from master having resize_and_overwrite implemented.

How to fix
The fix is very simple - replace auto with size_t inside the following line of resize_and_overwrite implementation:

const auto _Result_size = _STD move(_Op)(_Mypair._Myval2._Myptr(), _New_size);

Alternatively, contact compiler team to make them disable useless warning C4018 by default for x86 builds (it is already disabled for x64 builds).

[fsb4000]

Thank you.

I think we cannot replace auto with size_t because the diagnostic will be pointless

_STL_VERIFY(_Result_size >= 0, "the returned size can't be smaller than 0");

But I think I fixed the code and now it doesn't generate the warning.

[PowerGamer1]

@fsb4000

I think we cannot replace auto with size_t because the diagnostic will be pointless

I agree. To keep the first _STL_VERIFY working as intended returned size cannot be converted to size_t early.

But using cmp_less_equal might not be a good idea for the following reasons:

1. You introduce cmp_less_equal from <utility> into <string>. Is this allowed by the standard?
2. Using cmp_less_equal would increase compile time versus simply using static_cast<size_t>.

When first of two consecutive _STL_VERIFY fails then all bets are off and we don't have to ensure the second _STL_VERIFY works correctly too, right? If so I think it would be better to just use:

_STL_VERIFY(static_cast<size_t>(_Result_size) <= _New_size, "the returned size can't be greater than the passed size");

for the second check.

Also, why did you add explicit conversion here:

_Eos(static_cast<size_type>(_Result_size));

[fsb4000]

1. You introduce cmp_less_equal from <utility> into <string>. Is this allowed by the standard?

Yes.

2. Using cmp_less_equal would increase compile time versus simply using static_cast<size_t>.

You are correct.

_STL_VERIFY(static_cast<size_t>(_Result_size) <= _New_size, "the returned size can't be greater than the passed size");

I don't know :(

size_t is uint32_t on X86, so if _Result_size is int64_t then the static_cast<size_t>(_Result_size) <= _New_size could not catch something that cmp_less_equal could catch. For example,

constexpr long long _Result_size = UINT32_MAX + 2LL;
static_assert(static_cast<uint32_t>(_Result_size) == 1);

But @cpplearner found that cmp_less_equal doesn't work with _Unsigned128 :(

Also, why did you add explicit conversion here:

Because I got another warning without the static_cast.

xstring(3977): warning C4365: 'argument': conversion from 'const int' to 'const unsigned int', signed/unsigned mismatch

[PowerGamer1]

So (correct me if I am wrong) the original two checks:

_STL_VERIFY(_Result_size >= 0, "the returned size can't be smaller than 0");
_STL_VERIFY(_Result_size <= _New_size, "the returned size can't be greater than the passed size");

work perfectly fine for any allowed type of _Result_size and are easy to read and understand. If so just shut the compiler up with #pragam warning instead of inventing complex workarounds for non-existing problem.