Re: else ladders practice

On 05/11/2024 20:39, Waldek Hebisch wrote:

David Brown <david.brown@hesbynett.no> wrote:

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

Bart <bc@freeuk.com> wrote:

>
Then we disagree on what 'multi-way' select might mean. I think it means
branching, even if notionally, on one-of-N possible code paths.

>
OK.

>
I appreciate this is what Bart means by that phrase, but I don't agree
with it.  I'm not sure if that is covered by "OK" or not!

 You may prefer your own definition, but Bart's is resonable one.

The only argument I can make here is that I have not seen "multi-way select" as a defined phrase with a particular established meaning.  So it simply means what the constituent words mean - selecting something from multiple choices.  There are no words in that phrase that talk about "branching", or imply a specific order to events.  It is a very general and vague phrase, and I cannot see a reason to assume it has such a specific meaning as Bart wants to assign to it.  And as I have pointed out in other posts, there are constructs in many languages (including C) that fit the idea of a selection from one of many things, but which do not fit Bart's specific interpretation of the phrase.
Bart's interpretation is "reasonable" in the sense of being definable and consistent, or at least close enough to that to be useable in a discussion.  But neither he, I, or anyone else gets to simply pick a meaning for such a phrase and claim it is /the/ definition.  Write a popular and influential book with this as a key phrase, and /then/ you can start calling your personal definition "the correct" definition.

 

  

The whole construct may or may not return a value. If it does, then one
of the N paths must be a default path.

>
>
You need to cover all input values.  This is possible when there
is reasonably small number of possibilities.  For example, switch on
char variable which covers all possible values does not need default
path.  Default is needed only when number of possibilities is too
large to explicitely give all of them.  And some languages allow
ranges, so that you may be able to cover all values with small
number of ranges.
>

>
I think this is all very dependent on what you mean by "all input values".
>
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.

 Well, some languages treat types more seriously than C.  In Pascal
type of your input would be 0..10 and all input values would be
handled.  Sure, when domain is too complicated to express in type
than it could be documented restriction.  Still, it makes sense to
signal error if value goes outside handled rage, so in a sense all
values of input type are handled: either you get valid answer or
clear error.

No, it does not make sense to do that.  Just because the C language does not currently (maybe once C++ gets contracts, C will copy them) have a way to specify input sets other than by types, does not mean that functions in C always have a domain matching all possible combinations of bits in the underlying representation of the parameter's types.
It might be a useful fault-finding aid temporarily to add error messages for inputs that are invalid but can physically be squeezed into the parameters.  That won't stop people making incorrect declarations of the function and passing completely different parameter types to it, or finding other ways to break the requirements of the function.
And in general there is no way to check the validity of the inputs - you usually have no choice but to trust the caller.  It's only in simple cases, like the example above, that it would be feasible at all.
There are, of course, situations where the person calling the function is likely to be incompetent, malicious, or both, and where there can be serious consequences for what you might prefer to consider as invalid input values.  You have that for things like OS system calls - it's no different than dealing with user inputs or data from external sources. But you handle that by extending the function - increase the range of valid inputs and appropriate outputs.  You no longer have a function that takes a number between 0 and 10 and returns the integer square root - you now have a function that takes a number between -(2 ^ 31 + 1) and (2 ^ 31) and returns the integer square root if the input is in the range 0 to 10 or halts the program with an error message for other inputs in the wider range.  It's a different function, with a wider set of inputs - and again, it is specified to give particular results for particular inputs.

 

This is, IMHO, just nonsense and misunderstands the contract between
function writers and function users.
>
Further, I am confident that these people are quite happen to write code
like :
>
// 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];
}

 I do not think that people wanting strong type checking are happy
with C.  Simply, either they use different language or use C
without bitching, but aware of its limitations. 

Sure.  C doesn't give as much help to writing correct programs as some other languages.  That doesn't mean the programmer can't do the right thing.

I certainly would
be quite unhappy with code above.  It is possible that I would still
use it as a compromise (say if it was desirable to have single
prototype but handle points in spaces of various dimensions),
but my first attempt would be something like:
 typedef struct {int p[2];} two_int;
....
 

I think you'd quickly find that limiting and awkward in C (but it might be appropriate in other languages).  But don't misunderstand me - I am all in favour of finding ways in code that make input requirements clearer or enforceable within the language - never put anything in comments if you can do it in code.  You could reasonably do this in C for the first example :
// Do not use this directly
extern int small_int_sqrt_implementation(int x);
// Return the integer square root of numbers between 0 and 10
static inline int small_int_sqrt(int x) {
assert(x >= 0 && x <= 10);
return small_int_sqrt_implementation(x);
}
There is no way to check the validity of pointers in C, but you might at least be able to use implementation-specific extensions to declare the function with the requirement that the pointer not be null.

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?).

 I am certainly unhappy with overflow handling in current hardware
an by extention with overflow handling in C.
 

A function should accept all input values - once you have made clear
what the acceptable input values can be.  A "default" case is just a
short-cut for conveniently handling a wide range of valid input values -
it is never a tool for handling /invalid/ input values.

 Well, default can signal error which frequently is right handling
of invalid input values.
 

Will that somehow fix the bug in the code that calls the function?
It can be a useful debugging and testing aid, certainly, but it does not make the code "correct" or "safe" in any sense.