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

[carewolf]

unsigned overflow makes index smaller, i.e. if anything, it can protect against buffer overflow. you are talking about something else

Underflow is also a type of overflow.

[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

[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.

[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]

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 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()

[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.

[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

[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; }`

[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.