Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: So You Think You Can Const?
Date: Mon, 13 Jan 2025 10:05:25 +0100
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <vm2l0l$1n8gc$2@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> <vm1foe$2s6l0$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 13 Jan 2025 10:05:25 +0100 (CET)
Injection-Info: dont-email.me; posting-host="515b9a709d729126ae8355fc1ec2f38f";
	logging-data="1810956"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/dS1peQO+XP5Itb9uzGoTuskiVuaVT9AE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:Q/e/pwLCTtiSHOawz79F22ZnaDA=
In-Reply-To: <vm1foe$2s6l0$1@paganini.bofh.team>
Content-Language: en-GB
Bytes: 4015

On 12/01/2025 23:29, Waldek Hebisch wrote:
> Ben Bacarisse <ben@bsb.me.uk> 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;
>>>>>
>>>>>       pT = malloc(sizeof(AvlTree_t));
>>>>>
>>>>>       if (!pT) {
>>>>>           return NULL;
>>>>>       }
>>>>>
>>>>>       pT->pk = pk;
>>>>>       pT->pL = pL;
>>>>>       pT->pR = pR;
>>>>>
>>>>>       return pT;
>>>>> }
>>>> Just on a side issue, I prefer to make tests like this positive so I'd
>>>> write:
>>>>    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,
>>
>> I would be happy for you to expand on why you say that.
> 
> Julio did not want to give his reasons, but I have reasons to
> prefer "negative" version too.  Namely, significant trouble
> with malloc is ensuring correct handling of failing case.
> Since this code is not excercised by normal execution, this
> should be done by robust coding pattern.  In particular,
> it is easier to check correctness when handling code is
> immediately after 'malloc' and the test.  So
> 
>      AvlTree_t *pT = malloc(*pT);
>      if (!pT) {
>          return pT;
>      }
>      ...
> 
> makes quite visible that handling is there and it is rather
> minimal (in particular caller have to cope with null pointer
> return).  That is easily lost in "posive" version, where
> error handling may be far away from the allocation and test.
> 
> Basically, this is similar idea to "defer" discussed in
> another thread, just in this case requires no language
> extention and simply adopting appropriate coding style
> gives the effect.
> 

"defer" can help for some types of cleanup, but won't help here - you 
can't "defer" an bail-out from the main function - a "return" in the 
deferred code returns from the deferred function, not the main function. 
  At least, that is the case with the macro / gcc local function version 
of "defer".  A "defer" language feature might be different.