Post might have signed integer overflow => undefined behaviour => delete all the code in mind. Which can be avoided if you remember that hazard is there.
What's integer divide by zero in C? Would you consider that safe?
> Which can be avoided if you remember that hazard is there.
This is true, but it could be argued that it's harder to avoid signed integer overflow in C/C++ than it is to avoid buffer overflows: you often don't know what types you're working with, due to the usual arithmetic conversions and integer promotions, and checking whether an overflow will occur without causing an overflow is difficult in itself. It's kind of uniquely awful in this respect, basically every other popular language has a more practical integer programming model.
I like integer overflow being UB. Makes it easier to check for by enabling a sanitizer.
With it being defined as wrapping, it would be illegal for overflow to cause a runtime trap.
Of course, rust mandates the trap on debug builds, which is a fine approach too.
Yes, because, as all C newbies can easily explain to you, the general rule of thumb is that undefined behavior should be treated as a fault and thus should be handled as a bug.
Hence, your question reads as "Would you consider a bug to be safe?".
In case of integer division, you simply need to check that the divisor is not zero prior to executing the division. Done.
People new to C hear about UB, resolve to not do that, and that seems fine.
People not new to C have noticed that so many constructs are UB as to make it infeasible in practice that any given codebase will be free of UB.
What makes C a fundamentally unsafe language is that conceptually minor errors have unspecified consequences of unbounded magnitude, limited to no compile time detection of said errors, and that even builtins like + are specified to compile successfully into nonsense in some contexts.
Integer operations can be defined to be safe. Whatever integers you pass to your maths operation, you get an unsurprising integer back.
What the language does in the presence of your bug is definitely part of the safety properties of the language.
> What makes C a fundamentally unsafe language is that conceptually minor errors have conceptually unspecified consequences of unbounded magnitude.
There, fixed that for you.
Everybody knows that these scary stories can happen (even though almost nobody has seen them happen in the wild). But for the most part they should be seen as a combination of (typically, obviously) buggy code and compiler optimizer defects, rather than fundamental defects of the language.
> Integer operations can be defined to be safe. Whatever integers you pass to your maths operation, you get an unsurprising integer back.
There is at least 1 arithmetics teacher disagreeing with you.
There is no point, and let me scream again NO FR**G POINT, for a zero divide to return zero. I want it to crash.
And I consider it a compiler defect if the compiler proves that a zero division is happening and proceeds to do a strange optimization instead of reporting it.
It's a fine line to walk though, since there is also the case of legitimately assuming that it doesn't happen, and not emitting the code that triggers the crash. There probably should be compiler knobs to tune the behaviour.
Decent chance integer divide by zero will kill your process. Might even call it a floating point exception. Maybe that qualifies as safe to you, seems not-safe to me.
Compelling alternative would be for it to return zero. Which is safe. But C doesn't do that. So you have to remember to never write '/', and instead call my_divide, which has a branch in it.
>Compelling alternative would be for it to return zero.
That's actually way less safe than crashing. If your code doesn't handle the case where the denominator is zero, it is likely that the logic around your division doesn't consider it either. The behavior you suggest would take a rapidly increasing number and instantaneously set it to 0, then silently pass it into the logic that was humming along up to that point.
Since there's no symbol for NaN in integers, there is no safe way to represent `x / 0`, and thus the best way to handle it is to fault. Even better would be if the compiler caught it and warned you.
> Even better would be if the compiler caught it and warned you
Which is probably what the big compilers do (seems reasonable to expect it) -- I can't really know though because the last time I've written code that divides by 0 in an easily provable way is probably a long time ago.
What's integer divide by zero in C? Would you consider that safe?