131–140 of 153 posts
Earlier quoted context omitted.
Usually you don't do arithmetic with char in Java, this isn't C culture of anything goes.
It is not even possible to do arithmetic on char in C.
#include
unsigned int pack_rgb(unsigned char r, unsigned char g, unsigned char b) {
return (r I would expect a better comment from someone working on the standard.
I don't recall similar arguments being made for Pascal or ADA.
Look around at the state of our C++ and C software and all the CVEs I think we probably shouldn't care about unsigned or signed loop indexes and move on before regulatory pressure forces us. Please language designers, give us some interesting alternatives to Rust.
Earlier quoted context omitted.
Maybe this isn't what you're suggesting, but it's already possible to make an interface that prevents callers from doing math on indices in Rust — just return a struct that has a private member for the index. The caller can pass the value back at which point you can unwrap it and do index arithmetic.
More than that, in theory an opaque handle would also do things like statically prevent a handle taken from one array from being used to access a different array. I feel like this should be possible in Rust with type-level shenanigans (e.g. GhostCell).
It's not really signed vs unsigned that's the issue, IMO. It's (mostly, in C) undefined behavior and implicit conversions? I'm not sure Go is saner just because len is an int. Well, maybe, depending on how you look at it. Defining len to be signed int, means the largest valid len is half your address space, which also means half of all possible indexes are always invalid; which makes some things easier. But it's real…
For signed overflow we have sanitizers, and for conversions C compilers warnings in C. Bounds checking can also be done with sanitizers (but is a bit more tricky). So no, I do not think the undefined behavior is really a big problem. In fact, it helps us find the problem because every overflow can be considered a programming error. Error due to unsigned wraparound are a much bigger issue, because the lead to subtle i…
High performance, lock-free FIFOs/channels are commonly implemented in a way that requires overflow.
Earlier quoted context omitted.
For signed overflow we have sanitizers, and for conversions C compilers warnings in C. Bounds checking can also be done with sanitizers (but is a bit more tricky). So no, I do not think the undefined behavior is really a big problem. In fact, it helps us find the problem because every overflow can be considered a programming error. Error due to unsigned wraparound are a much bigger issue, because the lead to subtle i…
> Error due to unsigned wraparound are a much bigger issue This is a type design mistake. The unsigned integers should not wrap by default . It makes absolute sense, given all the constraints and the fact that it's doing New Jersey "implementation simplicity dominates" design that K&R C only provides a wrapping unsigned type, but that's an excuse for K&R C which is a 1960s programming language. The excuse gets shakie…
What would you do instead?
Earlier quoted context omitted.
> Error due to unsigned wraparound are a much bigger issue This is a type design mistake. The unsigned integers should not wrap by default . It makes absolute sense, given all the constraints and the fact that it's doing New Jersey "implementation simplicity dominates" design that K&R C only provides a wrapping unsigned type, but that's an excuse for K&R C which is a 1960s programming language. The excuse gets shakie…
> The unsigned integers should not wrap by default. What would you do instead?
Then, dedicated APIs for wrapping behavior where you expect it to happen.
Earlier quoted context omitted.
> The unsigned integers should not wrap by default. What would you do instead?
How about just panic? If a wrap happens and you don't expect it, it's almost always a severe bug. Then, dedicated APIs for wrapping behavior where you expect it to happen.
Earlier quoted context omitted.
It is not even possible to do arithmetic on char in C.
#include unsigned int pack_rgb(unsigned char r, unsigned char g, unsigned char b) { return (r Compiler Explorer link, https://godbolt.org/z/3jExdaTT9 I would expect a better comment from someone working on the standard.
Earlier quoted context omitted.
The point is that you can get the warnings without having to deal with a strict type system all the time.
Warnings are just noise, so there's no point in printing them--they will be ignored (maybe not when there is a singular warning, but if warnings are allowed to accumulate beyond some manageable threshold). If a warning is worth printing, it should be treated as an error, and if you treat it as an error, you now are "strict" by definition.