Hacker News Reader

Comment by saagarjha | Hacker News Reader

That doesn't make the program incorrect, it just means that you can't provide that particular input to the program.

The problem is that UB is invoked on runtime for particular inputs... And it silently makes program unreasonable after this point.

That is not good. It's hard to reason about such a program, in other words can you trust results of such a program? How do you know whether your input caused Ub at some point or not?

The burden of sanitizing the input is on the user (either programmer or the data provider).

Checking this is usually a performance tradeoff, so it was decided not to be done by default.

That's a documentation/sanitization problem, rather than a one involving the question of whether this program is well-formed. My response was that it is, given the input obeys the rules you've stated. How you enforce that is a different concern (or whether you dislike the preconditions and think this code could be more robust and have a wider domain, because it certainly could).

a program which has undefined behaviour on some inputs is an incorrect program by definition

I'll have to disagree with you there: you cannot fully control the range of inputs that you are provided at all times, or perform verification of input. But you can clearly document what conditions the input must satisfy for the program to be well-defined.

Yes, but the "can't" really is a "shouldn't".

Point taken; unfortunately I can't edit anymore…

Reply on news.ycombinator.com