3 ms·

>How does that matter? Because C is a low level language. It is not a mistake, it by design exposes hardware characteristics. If you don't care about that you

by tjoff 5y ago

>How does that matter? Because C is a low level language. It is not a mistake, it by design exposes hardware characteristics. If you don't care about that you probably shouldn't be using C. I am the first to agree that undefined behavior in C is pretty bad. But this is trivially understood and one of the most basic examples. Can it still bite you in the ass? Sure. I would prefer it to be implementation defined, but relying on that blindly isn't much better anyway.

tialaramex 5y ago
Undefined Behaviour doesn't "expose hardware characteristics". I assure you that the effect in hardware is not undefined. It would be interesting to survey Rust programs here. Rust's abs() on normal signed integer types function panics on overflow except in release builds (where it does the same as wrapping_abs) Rust's wrapping_abs() gives MIN because that's what happens in two's complement arithmetic when you wrap around beyond MAX, this is probably undesirable for most people most of the time. Rust's saturating_abs() gives MAX here, I would expect lots of programmers want that. The Wrapping<T> and Saturating<T> types have abs() do what wrapping_abs() or saturating_abs() accordingly do on the basic integer type.
- tjoff 5y ago
  Really struggling what your point is. I didn't say that undefined behavior expose hardware characteristics, though I suppose for a lot of cases it really does - but the compiler won't assume so. I said that C exposes hardware characteristics. And C also has several architectures in mind. Signed integer overflow is trivial on a two-complement system but not necessarily on others, so the lowest common denominator dictates what can be done. If the behavior is different or expensive you might shift that decision to the programmer. Negating the sign of INT_MIN isn't cheap to do in a two-complement system.
  - tialaramex 5y ago
    > I said that C exposes hardware characteristics. Nonsense isn't a characteristic of the hardware. The hardware has very clearly defined behaviour, but C chooses not to expose that.
    - tjoff 5y ago
      Well, how do you expose something that is different on different architectures? Maybe not define it? Anyway, doesn't seem like you are even trying to understand. No worries, I won't bother.
      - tialaramex 5y ago
        C is full of things that are different from one architecture to the next but don't have Undefined Behaviour. Instead they are: "Implementation Defined".
        deleted 5y ago
        [deleted]

by tjoff 5y ago

tialaramex 5y ago

Undefined Behaviour doesn't "expose hardware characteristics". I assure you that the effect in hardware is not undefined. It would be interesting to survey Rust programs here. Rust's abs() on normal signed integer types function panics on overflow except in release builds (where it does the same as wrapping_abs) Rust's wrapping_abs() gives MIN because that's what happens in two's complement arithmetic when you wrap around beyond MAX, this is probably undesirable for most people most of the time. Rust's saturating_abs() gives MAX here, I would expect lots of programmers want that. The Wrapping<T> and Saturating<T> types have abs() do what wrapping_abs() or saturating_abs() accordingly do on the basic integer type.

tjoff 5y ago
Really struggling what your point is. I didn't say that undefined behavior expose hardware characteristics, though I suppose for a lot of cases it really does - but the compiler won't assume so. I said that C exposes hardware characteristics. And C also has several architectures in mind. Signed integer overflow is trivial on a two-complement system but not necessarily on others, so the lowest common denominator dictates what can be done. If the behavior is different or expensive you might shift that decision to the programmer. Negating the sign of INT_MIN isn't cheap to do in a two-complement system.
- tialaramex 5y ago
  > I said that C exposes hardware characteristics. Nonsense isn't a characteristic of the hardware. The hardware has very clearly defined behaviour, but C chooses not to expose that.
  - tjoff 5y ago
    Well, how do you expose something that is different on different architectures? Maybe not define it? Anyway, doesn't seem like you are even trying to understand. No worries, I won't bother.
    - tialaramex 5y ago
      C is full of things that are different from one architecture to the next but don't have Undefined Behaviour. Instead they are: "Implementation Defined".
      - deleted 5y ago
        [deleted]