Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Sun, 10 Nov 2024 16:13:21 +0100
Organization: A noiseless patient Spider
Lines: 95
Message-ID: <vgqiii$edif$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>
 <vgn0vl$3kr82$1@dont-email.me> <vgnfnd$3nmui$1@dont-email.me>
 <vgpcdv$7jqv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 10 Nov 2024 16:13:24 +0100 (CET)
Injection-Info: dont-email.me; posting-host="bc3fb36d862bb47645172da8c39e0aa4";
	logging-data="472655"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/+QmxZo9xc6tixrJ8tdf7zTL6S5MFOulY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:7JjDv2h00UYY0xWzmIxA4i+HSaM=
Content-Language: en-GB
In-Reply-To: <vgpcdv$7jqv$1@dont-email.me>

On 10/11/2024 05:22, Janis Papanagnou wrote:
> On 09.11.2024 12:06, David Brown wrote:
>> On 09/11/2024 07:54, Janis Papanagnou wrote:
>>>
>>> Well, it's a software system design decision whether you want to
>>> make the caller test the preconditions for every function call,
>>> or let the callee take care of unexpected input, or both.
>>>
>>
>> Well, I suppose it is their decision - they can do the right thing, or
>> the wrong thing, or both.
>>
>> I believe I explained in previous posts why it is the /caller's/
>> responsibility to ensure pre-conditions are fulfilled, and why anything
>> else is simply guaranteeing extra overheads while giving you less
>> information for checking code correctness.  But I realise that could
>> have been lost in the mass of posts, so I can go through it again if you
>> want.
> 
> I haven't read all the posts, or rather, I just skipped most posts;
> it's too time consuming.

I should probably have skipped /writing/ the posts - it was too time 
consuming :-)

> 
> Since you explicitly elaborated - thanks! - I will read this one...
> 
>> [...]
>>
>> (On security boundaries, system call interfaces, etc., where the caller
>> could be malicious or incompetent in a way that damages something other
>> than their own program, you have to treat all inputs as dangerous and
>> sanitize them, just like data from external sources.  That's a different
>> matter, and not the real focus here.)
>>
>>> We had always followed the convention to avoid all undefined
>>> situations and always define every 'else' case by some sensible
>>> behavior, at least writing a notice into a log-file, but also
>>> to "fix" the runtime situation to be able to continue operating.
>>> (Note, I was mainly writing server-side software where this was
>>> especially important.)
>>
>> You can't "fix" bugs in the caller code by writing to a log file.
>> Sometimes you can limit the damage, however.
> 
> I spoke more generally of fixing situations (not only bugs).

OK.  It can certainly help with /finding/ bugs, that can then be fixed 
later.

> 
>>
>> If you can't trust the people writing the calling code, then that should
>> be the focus of your development process - find a way to be sure that
>> the caller code is right.  That's where you want your conventions, or to
>> focus code reviews, training, automatic test systems - whatever is
>> appropriate for your team and project.  Make sure callers pass correct
>> data to the function, and the function can do its job properly.
> 
> Yes.
> 
>>
>> Sometimes it makes sense to specify functions differently, and accept a
>> wider input.  Maybe instead of saying "this function will return the
>> integer square root of numbers between 0 and 10", you say "this function
>> will return the integer square root if given a number between 0 and 10,
>> and will log a message and return -1 for other int values".  Fair enough
>> - now you've got a new function where it is very easy for the caller to
>> ensure the preconditions are satisfied.  But be very aware of the costs
>> - you have now destroyed the "purity" of the function, and lost the key
>> mathematical relation between the input and output.  (You have also made
>> everything much less efficient.)
> 
> I disagree in the "much less" generalization. I also think that when
> weighing performance versus safety my preferences might be different;
> I'm only speaking about a "rule of thumb", not about the actual (IMO)
> necessity(!) to make this decisions depending on the project context.
> 

My preferences are very much weighted towards correctness, not 
efficiency.  That includes /knowing/ that things are correct, not just 
passing some tests.  And key to that is knowing facts about the code 
that can be used to reason about it.  If you have a function that has 
clear and specific pre-conditions, you know what you have to do in order 
to use it correctly.  It can then give clear and specific 
post-conditions, and you can use these to reason further about your 
code.  On the other hand, if the function can, in practice, take any 
input then you have learned little.  And if it can do all sorts of 
different things - log a message, return an arbitrary "default" value, 
etc., - then you have nothing to work with for proving or verifying the 
rest of your code.