Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: So You Think You Can Const?
Date: Thu, 9 Jan 2025 13:37:09 -0800
Organization: A noiseless patient Spider
Lines: 107
Message-ID: <vlpfi5$3hn08$7@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> <20250108200758.563@kylheku.com>
 <vlo59o$39tcu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 09 Jan 2025 22:37:10 +0100 (CET)
Injection-Info: dont-email.me; posting-host="dc9a5d5b35debff00bf53408719c9f31";
	logging-data="3726344"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19UaERY3V+fuU6ZU7yNnpiYuWfWXLDGhGc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6Z0jNSLrB0z6p68x+OMqxiMUMzc=
In-Reply-To: <vlo59o$39tcu$1@dont-email.me>
Content-Language: en-US
Bytes: 4649

On 1/9/2025 1:35 AM, David Brown wrote:
> On 09/01/2025 05:24, Kaz Kylheku wrote:
>> On 2025-01-09, Ben Bacarisse <ben@bsb.me.uk> 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;
>>>   }
>>
>> More generally:
>>
>>     foo_handle *foo = foo_create();
>>     bar_handle *bar = foo ? bar_create(foo) : 0; // doesn't like null
>>     xyzzy_handle *xyz = xyzzy_create(42, bar, arg);
>>     container *con = malloc(sizeof *con);
>>
>>     if (foo && bar && xyz && con) {
>>       // happy case: we have all three resources
>>
>>       con->foo = foo;
>>       con->bar = bar;
>>       con->xyz = xyz;
>>
>>       return con;
>>     }
>>
>>     xyzzy_destroy(xyz);
>>     xyzzy_destroy(bar);
>>     if (foo)
>>        xyzzy_destroy(foo); // stupidly doesn't like null
>>
>>     return 0;
>>
>>> 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.
>>
>> I might just have made the case. When more resources need to be
>> acquired that might fail, it consolidates the happy case under one
>> conjunctive test, and consolidates the cleanup in the unhappy case.
>> Effectively it's almost if we have only two cases.
>>
>> A minor disadvantage is that in the unhappy flow, we may allocate
>> resources past the point where it is obvious they are not going to be
>> needed: if foo_create() failed, we are pointlessly calling
>> xyzzy_create() and malloc for the container. It's possible that these
>> succeed, and we are just going to turn around and free them.
>>
> 
> How about taking the idea slightly further and making the later 
> allocations conditional too?
> 
>     foo_handle *foo = foo_create();
>     bar_handle *bar = foo ? bar_create(foo) : 0; // doesn't like null
>     xyzzy_handle *xyz = bar ? xyzzy_create(42, bar, arg) : 0;
>     container *con = xyz ? malloc(sizeof *con) : 0;
> 
>     if (con) {
>       // happy case: we have all three resources
> 
>     ...
> 
> If you are going to use that style (and I not arguing for or against 
> it), go all in!

Indeed! :^D


> 
> 
>> It's a form of consolidated error checking, like when we make
>> several system calls and check them for errors as a batch;
>> e.g. call fprintf several times and check for disk full (etc)
>> just once.
>>
> 
> 
>