Re: else ladders practice

On 04/11/2024 22:25, David Brown wrote:

On 04/11/2024 20:50, Bart wrote:

But it could for n==4.

 Again, you /completely/ miss the point.
 If you have a function (or construct) that returns a correct value for inputs 1, 2 and 3, and you never pass it the value 4 (or anything else), then there is no undefined behaviour no matter what the code looks like for values other than 1, 2 and 3.  If someone calls that function with input 4, then /their/ code has the error - not the code that doesn't handle an input 4.

This is the wrong kind of thinking.
If this was a library function then, sure, you can stipulate a set of input values, but that's at a different level, where you are writing code on top of a working, well-specified language.
You don't make use of holes in the language, one that can cause a crash. That is, by allowing a function to run into an internal RET op with no provision for a result. That's if there even is a RET; perhaps your compilers are so confident that that path is not taken, or you hint it won't be, that they won't bother!
It will start executing whatever random bytes follow the function.
As I said in my last post, a missing return value caused an internal error in one of my C implementations because a pushed return value was missing.
How should that be fixed, via a hack in the implementation which pushes some random value to avoid an immediate crash? And then what?
Let the user - the author of the function - explicitly provide that value then at least that can be documented: if N isn't in 1..3, then F returns so and so.
You know that makes perfect sense, but because you've got used to that dangerous feature in C you think it's acceptable.