Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Mon, 4 Nov 2024 23:44:34 +0000
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <vgbm91$15rph$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg0t3j$2ruor$1@dont-email.me>
 <78eabb4054783e30968ae5ffafd6b4ff2e5a5f17@i2pn2.org>
 <vg2g37$37mh3$1@dont-email.me> <6724CFD2.4030607@grunge.pl>
 <vg2llt$38ons$1@dont-email.me>
 <2491a699388b5891a49ef960e1ad8bb689fdc2ed@i2pn2.org>
 <b681ee05856e165c26a5c29bf42a8d9d53843d6d@i2pn2.org>
 <vg2ttn$3a4lk$1@dont-email.me> <vg33gs$3b8n5$1@dont-email.me>
 <vg358c$3bk7t$1@dont-email.me> <vg37nr$3bo0c$1@dont-email.me>
 <vg3b98$3cc8q$1@dont-email.me> <vg5351$3pada$1@dont-email.me>
 <vg62vg$3uv02$1@dont-email.me> <vg8a84$euka$1@dont-email.me>
 <vg8koq$gpsg$1@dont-email.me> <vgat50$112jp$1@dont-email.me>
 <vgb8if$13ioj$1@dont-email.me> <vgbhkt$155v2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 05 Nov 2024 00:44:33 +0100 (CET)
Injection-Info: dont-email.me; posting-host="cf8ab2f706c64865e8fbf40d9cba7390";
	logging-data="1240881"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/oiWzJcu00vEOL6JVo/f/3"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:678oQ2lfhvPT1RvpKEBnPXlf47o=
Content-Language: en-GB
In-Reply-To: <vgbhkt$155v2$1@dont-email.me>
Bytes: 3474

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.