Re: else ladders practice

On 05/11/2024 13:29, David Brown wrote:

On 05/11/2024 13:42, Waldek Hebisch wrote:

 Supposing I declare this function:
 // Return the integer square root of numbers between 0 and 10
int small_int_sqrt(int x);
  To me, the range of "all input values" is integers from 0 to 10.  I could implement it as :
 int small_int_sqrt(int x) {
     if (x == 0) return 0;
     if (x < 4) return 1;
     if (x < 9) return 2;
     if (x < 16) return 3;
     unreachable();
}

 If the user asks for small_int_sqrt(-10) or small_int_sqrt(20), that's /their/ fault and /their/ problem.  I said nothing about what would happen in those cases.
 But some people seem to feel that "all input values" means every possible value of the input types, and thus that a function like this should return a value even when there is no correct value in and no correct value out.

Your example is an improvement on your previous ones. At least it attempts to deal with out-of-range conditions!
However there is still the question of providing that return type. If 'unreachable' is not a special language feature, then this can fail either if the language requires the 'return' keyword, or 'unreachable' doesn't yield a compatible type (even if it never returns because it's an error handler).
Getting that right will satisfy both the language (if it cared more about such matters than C apparently does), and the casual reader curious about how the function contract is met (that is, supplying that promised return int type if or when it returns).

// Take a pointer to an array of two ints, add them, and return the sum
int sum_two_ints(const int * p) {
     return p[0] + p[1];
}
 Perhaps, in a mistaken belief that it makes the code "safe", they will add :
      if (!p) return 0;
 at the start of the function.  But they will not check that "p" actually points to an array of two ints (how could they?), nor will they check for integer overflow (and what would they do if it happened?).

This is a different category of error.
Here's a related example of what I'd class as a language error:
    int a;
    a = (exit(0), &a);
A type mismatch error is usually reported. However, the assignment is never done because it never returns from that exit() call.
I expect you wouldn't think much of a compiler that didn't report such an error because that code is never executed.
But to me that is little different from running into the end of function without the proper provisions for a valid return value.