5 ms·

I write software for spacecraft. I’d much rather take my chances that the overflowed value is meant for humans or for some tertiary system than to end the missi

by nynx 3y ago

I write software for spacecraft. I’d much rather take my chances that the overflowed value is meant for humans or for some tertiary system than to end the mission regardless.

bvrmn 3y ago
Oh shi, not very reassuring knowledge spacecraft SW engineers allow signed overflow in their code.
- Am4TIfIsER0ppos 3y ago
  I would guess they don't use a language where signed overflow is undefined. I use C all day every day and that's gotta be one of the worst legacy artefacts of it. As someone else said "it isn't 1970" the system is twos complement.
  - bvrmn 3y ago
    Defined silent signed overflow (wrapping) is worse then UB. For UB there is at least runtime diagnostic. Parent clearly ok with `-fwrapv`.
    - Dylan16807 3y ago
      > For UB there is at least runtime diagnostic. I have no idea what you mean by this. A couple types have diagnostics, but so do overflow and wrapping. Most don't. In general, it's much easier to have runtime diagnostics for arithmetic than for UB. I guess if I squint and "silent" implies you're not allowed to install diagnostics, then it's worse? But that's so artificial of a comparison as to be silly.
  - Dylan16807 3y ago
    Even if the system is definitely twos complement, it's bad for i+1 to sometimes be less than i.
lxgr 3y ago
Unmanned spacecraft, hopefully? "Taking chances" is not a thing that I'd like the designers of a system that controls the vessel I'm on (or that overflies my house) routinely do during development. Undefined behavior can transitively expand to the entire system very quickly. For any subsystem, the proper error handling for an overflow/arithmetic error that's not properly handled right in the place it occurs is to declare the subsystem inoperative, not to keep going. If that approach routinely takes out too many and/or critical subsystems, you likely have much larger problems than integer overflows.

by nynx 3y ago

I write software for spacecraft. I’d much rather take my chances that the overflowed value is meant for humans or for some tertiary system than to end the mission regardless.

bvrmn 3y ago

Oh shi, not very reassuring knowledge spacecraft SW engineers allow signed overflow in their code.

Am4TIfIsER0ppos 3y ago
I would guess they don't use a language where signed overflow is undefined. I use C all day every day and that's gotta be one of the worst legacy artefacts of it. As someone else said "it isn't 1970" the system is twos complement.
- bvrmn 3y ago
  Defined silent signed overflow (wrapping) is worse then UB. For UB there is at least runtime diagnostic. Parent clearly ok with `-fwrapv`.
  - Dylan16807 3y ago
    > For UB there is at least runtime diagnostic. I have no idea what you mean by this. A couple types have diagnostics, but so do overflow and wrapping. Most don't. In general, it's much easier to have runtime diagnostics for arithmetic than for UB. I guess if I squint and "silent" implies you're not allowed to install diagnostics, then it's worse? But that's so artificial of a comparison as to be silly.
- Dylan16807 3y ago
  Even if the system is definitely twos complement, it's bad for i+1 to sometimes be less than i.

lxgr 3y ago

Unmanned spacecraft, hopefully? "Taking chances" is not a thing that I'd like the designers of a system that controls the vessel I'm on (or that overflies my house) routinely do during development. Undefined behavior can transitively expand to the entire system very quickly. For any subsystem, the proper error handling for an overflow/arithmetic error that's not properly handled right in the place it occurs is to declare the subsystem inoperative, not to keep going. If that approach routinely takes out too many and/or critical subsystems, you likely have much larger problems than integer overflows.