1:18:25 -- enjoyed this part. In a former job I was part-responsible for defining the local C++ style guide. Occasionally a new employee would cite that document and say "see, google says you're wrong". In addition to the points the presenter makes about code safety, I think there is a broader philosophical argument: types exist both to communicate to the compiler *and* to the reader. If you think it's important for your types to be "const-correct", then by similar logic I think you should want them to be "unsigned-correct". If in a code review I see a signed integer in a data structure or API, my first question is "in what circumstances will this value be negative?". If the answer is "never" then it should be communicating that fact to me using the type system. Otherwise I might be left thinking that it's meant to be mean something else (for instance, should it be set to -1 when an error happens?).
And for me it is the other way around: "Why is this value unsigned?" - if the answer is "cause i dont think i need negative numbers" then this also shows a lack of understanding of their own code.
@@ABaumstumpf It's a better understanding since he knows that he doesn't need negative numbers and communicates that via the defined return type. However, that's why you can specify your own types in Ada and also its range. Ada makes it easier to specify and engineer software.
I agree a common error with reverse loops and signedness are like the examples he shows. But I do not get why he does not show the traditional solution of using "for (i = size; i--;)" Or am I missing some obvious problem with this one?
If size is signed then a negative size is an issue so I think "for (size_t i = size; i; --i)" is safer and clearer for countdown through arrays to avoid array index bounds errors, but a ssize_t size would need to be checked explicitly anyway.
I wasn't sure where this talk was going to go. By the end, I wish there were time for the sized integer types section. The discussion was really interesting. The points around size_t and its purpose makes complete sense. I'll have to look into the implications on systems I work on
Not really, in the old days we had to thrash stuff out in order to have portability or hardware implementation optimisation. C was pragmatic, allowing implementations to run fast but differ in behaviour. People tend to be more heated over small points not truly complex ones beyond simple comprehension.
I haven't quite got the point. Is Robert arguing that one should stay away from signed types when security matters because signed types introduce UBs? It strikes me as odd.
Yes, UBs are very bad. A change in compiler option or the use of a different compiler can build the same program with different behaviors. A recoverable error may become catastrophic, or anything can happen, instead. I don't think anyone can guarantee that in large, complex software, all user inputs and intermediate calculated values are within ranges that no overflow can occur.
That do-while loop is just bugged (try with a size equal to zero). One could write `for (size_t i = size; i-- > 0; ) { /*...*/ }` (or `for (size_t i = size; i; ) { --i; /*...*/ }`, to avoid the warning with -fsanitize=unsigned-integer-overflow).
Another solution to the counted down loop is to use a while loop and adjust the array index i = size; while (i != 0) { array[i-1] = i; i--; } This also works for size == 0
Some people like to put it this way, but variable i becomes more cumbersome if you want to keep it around after breaking out of the loop (i.e. move its declaration before the loop): for(size_t i = size; i-- > 0;) { ... }
On 64bit platforms you basically don't need to bother with unrepresantable data sizes. I take nice signed arithmetic any day with defined near-zero behavior opposed to modular abomination. Google engineers are right in this regard.
if a committee can demand a type with range [-1, .. n] then why cant they also demand one with range [1, .. n] creating a numeric type that has no representation of 0, or make the type like null behavior and allow 0 as an exceptional value, perhaps calling this value 'null'
I was really hoping he would get to the fixed width integer types, choosing an integer type when size_t isn't relevant is one of the things I'm really not sure about.
I don't think the comment at 15:30 is correct. The volatile should inhibit that behaviour, the correct conclusion from "UB cannot happen" should be that the value of signed variable is such that si1*7 doesn't overflow, meaning that *7/7 does indeed correctly cancel out, which is why the code returns the original value. Without volatile and reasoning about the entire code, not just the single line, then yes, it could remove this code.
one of the questions 20 minutes in is kind of pissing me off. he needs to hear his own voice so much that he can't just explain his point in one short sentence
1:18:25 -- enjoyed this part. In a former job I was part-responsible for defining the local C++ style guide. Occasionally a new employee would cite that document and say "see, google says you're wrong".
In addition to the points the presenter makes about code safety, I think there is a broader philosophical argument: types exist both to communicate to the compiler *and* to the reader. If you think it's important for your types to be "const-correct", then by similar logic I think you should want them to be "unsigned-correct".
If in a code review I see a signed integer in a data structure or API, my first question is "in what circumstances will this value be negative?". If the answer is "never" then it should be communicating that fact to me using the type system. Otherwise I might be left thinking that it's meant to be mean something else (for instance, should it be set to -1 when an error happens?).
If I see an unsigned integer, my first question is: "Does this require module arithmetic?"
And for me it is the other way around:
"Why is this value unsigned?" - if the answer is "cause i dont think i need negative numbers" then this also shows a lack of understanding of their own code.
@@ABaumstumpf It's a better understanding since he knows that he doesn't need negative numbers and communicates that via the defined return type. However, that's why you can specify your own types in Ada and also its range. Ada makes it easier to specify and engineer software.
The value is unsigned because negative values are invalid. How hard is it to understand this?
What a funny and informative presentation !!!
Very seazoned prelegent and really invested in topic attenders, interesting discussions, uncommon views.
The commenter at 1:06:20 talking about "Undefined Behaviour" vs "unexpected behaviour" was pretty insightful. Programming is hard.
Excellent talk.
I agree a common error with reverse loops and signedness are like the examples he shows. But I do not get why he does not show the traditional solution of using "for (i = size; i--;)" Or am I missing some obvious problem with this one?
If size is signed then a negative size is an issue so I think "for (size_t i = size; i; --i)" is safer and clearer for countdown through arrays to avoid array index bounds errors, but a ssize_t size would need to be checked explicitly anyway.
I wasn't sure where this talk was going to go. By the end, I wish there were time for the sized integer types section.
The discussion was really interesting. The points around size_t and its purpose makes complete sense. I'll have to look into the implications on systems I work on
this is how deep the trouble is with both of the languages. It's the first time I hear such a heated debate.
Not really, in the old days we had to thrash stuff out in order to have portability or hardware implementation optimisation.
C was pragmatic, allowing implementations to run fast but differ in behaviour.
People tend to be more heated over small points not truly complex ones beyond simple comprehension.
I haven't quite got the point. Is Robert arguing that one should stay away from signed types when security matters because signed types introduce UBs? It strikes me as odd.
Yes, UBs are very bad. A change in compiler option or the use of a different compiler can build the same program with different behaviors. A recoverable error may become catastrophic, or anything can happen, instead. I don't think anyone can guarantee that in large, complex software, all user inputs and intermediate calculated values are within ranges that no overflow can occur.
It would be great Robert tell us how to use unsigned integers to do safe arithmetic (substruction) with signed promotion danger.
That do-while loop is just bugged (try with a size equal to zero). One could write `for (size_t i = size; i-- > 0; ) { /*...*/ }` (or `for (size_t i = size; i; ) { --i; /*...*/ }`, to avoid the warning with -fsanitize=unsigned-integer-overflow).
the do-while version is closest to the assembler output
NaN is also a legit in band error.
Another solution to the counted down loop is to use a while loop and adjust the array index
i = size;
while (i != 0) {
array[i-1] = i;
i--;
}
This also works for size == 0
But if size is signed and negative like -1 ssize_t bad things happen.
for (size_t i = size; i; --i) { foo[i-1] = i};
Is still not invulnerable.
i = size;
while( i )
array[ - - i ] = i;
size_t i = size;
while (i--)
I can't believe how programmers are so inexperienced in using simple for-loop.
for(size_t i = size; i > 0;) {
--i;
...
}
Some people like to put it this way, but variable i becomes more cumbersome if you want to keep it around after breaking out of the loop (i.e. move its declaration before the loop):
for(size_t i = size; i-- > 0;) {
...
}
fun talk
On 64bit platforms you basically don't need to bother with unrepresantable data sizes. I take nice signed arithmetic any day with defined near-zero behavior opposed to modular abomination. Google engineers are right in this regard.
if a committee can demand a type with range [-1, .. n] then why cant they also demand one with range [1, .. n] creating a numeric type that has no representation of 0, or make the type like null behavior and allow 0 as an exceptional value, perhaps calling this value 'null'
I was really hoping he would get to the fixed width integer types, choosing an integer type when size_t isn't relevant is one of the things I'm really not sure about.
Ask Fortran which integers are best.
I don't think the comment at 15:30 is correct. The volatile should inhibit that behaviour, the correct conclusion from "UB cannot happen" should be that the value of signed variable is such that si1*7 doesn't overflow, meaning that *7/7 does indeed correctly cancel out, which is why the code returns the original value.
Without volatile and reasoning about the entire code, not just the single line, then yes, it could remove this code.
OK, nvm, this was discussed by the same people few minutes later. 😅
@24:37 sounds like Fedor Pikus, is it?
The Man Himself.
one of the questions 20 minutes in is kind of pissing me off. he needs to hear his own voice so much that he can't just explain his point in one short sentence