Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Julio Di Egidio <julio@diegidio.name>
Newsgroups: comp.lang.c
Subject: Re: So You Think You Can Const?
Date: Wed, 15 Jan 2025 14:22:56 +0100
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <vm8crh$2uq21$5@dont-email.me>
References: <vljvh3$27msl$1@dont-email.me> <20250107130809.661@kylheku.com>
 <vlm0hf$2dkpd$1@dont-email.me> <87a5c15ob0.fsf@bsb.me.uk>
 <vlm7o4$2dkpd$4@dont-email.me> <vlm8r6$2dkpd$5@dont-email.me>
 <87ldvk4wu7.fsf@bsb.me.uk> <vlnrib$2dkpc$5@dont-email.me>
 <875xmn4lmy.fsf@bsb.me.uk> <vlpmkm$2dkpd$16@dont-email.me>
 <vlpn39$2dkpd$17@dont-email.me> <8634hr8muh.fsf@linuxsc.com>
 <vlpvpm$2dkpc$9@dont-email.me> <vlq1v6$2dkpd$18@dont-email.me>
 <vm206r$1gm6l$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 15 Jan 2025 14:22:57 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2563c1350cfe2ddd1cd2f0f3cf044725";
	logging-data="3106881"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18501Da3+i52xyKtQhKWr1iU+WImjC9y8U="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:EhyNHqMg+2ArR/MdjbW9Rk2gkt8=
Content-Language: en-GB
In-Reply-To: <vm206r$1gm6l$1@dont-email.me>
Bytes: 3639

On 13/01/2025 04:10, James Kuyper wrote:
> On 1/9/25 21:51, Julio Di Egidio wrote:
>> On 10/01/2025 03:14, Julio Di Egidio wrote:
> ...
>>>>>>> Julio Di Egidio <julio@diegidio.name> writes:
>>>>>>>
>>>>>>>> On 09/01/2025 02:09, Ben Bacarisse wrote:
>>>>>>>>
>>>>>>>>> Julio Di Egidio <julio@diegidio.name> writes:
> ...
>>>>>>>>>    static AvlTree_t const *AvlTree_node(
>>>>>>>>>    void const *pk, AvlTree_t const *pL, AvlTree_t const *pR
>>>>>>>>>    ) {
>>>>>>>>>    AvlTree_t *pT = malloc(*pT);
>>>>>>>>>    if (pT) {
>>>>>>>>>    pT->pk = pk;
>>>>>>>>>    pT->pL = pL;
>>>>>>>>>    pT->pR = pR;
>>>>>>>>>    }
>>>>>>>>>    return pT;
>>>>>>>>>    }
>>>>>>>>> I'm not going to "make a case" for this (though I will if you
>>>>>>>>> want!) -- I just think it helps to see lots of different styles.
>>>>>>>>
>>>>>>>> That is *more* error prone,
> ...
>>> ... check the return value as soon as the function returns a possibly
>>> null pointer or an error value is certainly more widely applicable,
>>> and quite less error prone, especially if it's
>>
>> I meant: immediately check the return value and bail out if needed.
>> The other approach does not even simplify on the clean-up, by the way...
> 
> The code you're criticizing as more error prone does check the return
> value as soon as the function returns, and bails out if needed.It just
> bails out through the missing else clause rather than from the if-clause.

LOL, the convincing arguments.  Tell that to your customer when things 
start going south: "it is formally equivalent"!

> It does requires code to be indented farther than the other approach. I

Sure, one level for each checked call, and that's still just the tip of 
that iceberg: I mean, are you serious or just you too sell bullshit for 
a living?  Not even my worst enemy I would bullshit that way.

> have avoided writing code like that for that reason, particularly when
> there's a lot of code inside the it statement's controlled blocks -but
> not because it's error prone.

It's called error prone when it's easy for the programmers to trip on 
it.  Get a real education for a change.

-Julio