GCC 12 Adds Stack Variable Auto-Initialization, Other Security Improvements Forthcoming

[doom_Oo7]

> That's not a proper solution, if vec has more than SSIZE_MAX (but less than SIZE_MAX) elements.

this is impossible on any currently existing 64-bit CPUs. The CPUs with the biggest address space, some specific AArch64 and POWER10, just have 52 & 51 bits addressable. Every x86_64 CPU in existance is limited to 48 bits. By the time we reach 63 addressable bits, size_t will already be 128...

[pal666]

That's not a proper solution, if vec has more than SSIZE_MAX (but less than SIZE_MAX) elements.
The only proper way is `if (vec.size() == 0) { /* just don't do this (and any subsequent code that would depends on any particular 'result' */ } else { result = vec.size() - 1; }`

your example is unrealistic, there are no vectors with 2^63 elements. proper size is signed(its unsignedness is just historic baggage). btw your solution is broken with - 2 and any other number.

[uxmkt]

and proper solution [...] ssize(vec) - 1

That's not a proper solution, if vec has more than SSIZE_MAX (but less than SIZE_MAX) elements.
The only proper way is `if (vec.size() == 0) { /* just don't do this (and any subsequent code that would depends on any particular 'result' */ } else { result = vec.size() - 1; }`

[F.Ultra]

Who in the right mind would want unsigned overflow protection?

And apparently GCC turned down adding such an option back in 2019 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91547#c1

[F.Ultra]

People using unsigned integers for buffer lengths. But yeah I do wonder how that would work with all the other stuff unsigned ints needs to do that does require overflow acting as prescribed.

Would be better if one could enable such warnings on say just size_t since that is more likely to be used for only buffer lengths than random unsigned integer.

[pal666]

I am just surprised that this option is not available.

it will be wall of noise in most programs. in places where you are concerned with promotions, you can use zero overhead abstraction in c++ which will do as you want. i know there are coding styles prohibiting promotions, maybe there are some accompanying tools, but it doesn't look practical. for solving out-of-bounds access issues it's much simpler to use .at(), or gsl::at()

[bluescarni]

yes, you are wrong. result wouldn't change if you replace 1 with 1u. compilers warn on mixed signedness comparison, but obviously only when it could matter(not when positive signed literal is promoted to unsigned)

You are right, but it is not about changing the result, it is about triggering an implicit integral conversion that changes signedness of one of the operands. Whether you are doing a == b or a + b, when sign-changing implicit integral promotion triggers I'd like the compiler to unconditionally warn me. I am just surprised that this option is not available.

[pal666]

I am dismayed that I cannot make GCC or Clang emit a warning for this code. I was sure that any compiler would complain about mixed unsigned/signed arithmetic, but apparently I was wrong.

yes, you are wrong. result wouldn't change if you replace 1 with 1u. compilers warn on mixed signedness comparison, but obviously only when it could matter(not when positive signed literal is promoted to unsigned)

[bluescarni]

vec.size() - 1

I am dismayed that I cannot make GCC or Clang emit a warning for this code. I was sure that any compiler would complain about mixed unsigned/signed arithmetic, but apparently I was wrong.

[quaz0r]

antifeatures yay! instead of spending time trying to figure out how to hold everyones hand and make code slower, please stay focused on actual features like improving codegen.

if someone wants their hand held thats fine, they can use rust