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: Fri, 10 Jan 2025 03:51:16 +0100
Organization: A noiseless patient Spider
Lines: 88
Message-ID: <vlq1v6$2dkpd$18@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 10 Jan 2025 03:51:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c30034bd4aee341f80baff0e07fd8dc5";
	logging-data="2544429"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+nMaGOburNuNFgRNxmYAiKcw+333l1fuY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gxuihTgPnH3emt/4X+K/J7rOZ4I=
Content-Language: en-GB
In-Reply-To: <vlpvpm$2dkpc$9@dont-email.me>
Bytes: 4631

On 10/01/2025 03:14, Julio Di Egidio wrote:
> On 10/01/2025 02:43, Tim Rentsch wrote:
>> Julio Di Egidio <julio@diegidio.name> writes:
>>
>>> On 10/01/2025 00:37, Julio Di Egidio wrote:
>>>
>>>> On 10/01/2025 00:23, Ben Bacarisse 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.
>>>>>
>>>>>> all the more so if it's not a 5 liner...
>>>>
>>>> There is no such thing as expanding 40 years of professional
>>>> experience in software engineering and programming and doing it
>>>> properly since day one:  just think about that code and what I said
>>>> for what it's worth, in particular I haven't mentioned 5 liners by
>>>> chance, things are quite more complicated not in vitro.
>>>>
>>>> And please do not hold a grudge about that:  it's not me who was
>>>> trying to say how to write code... ;)
>>>
>>> BTW, I hadn't mention it, but have you noticed the second one is
>>> misindented?  Between me and you, I can tell how long a piece of
>>> code will take to break when in production by just looking at
>>> it...  A lot of fun.  :)
>>
>> The indentation was correct in Ben's original posting.
>>
>> The misindentation first appeared in your followup to that
>> posting, where the quoted portion had been changed to remove a
>> blank line and over-indent the if().
> 
> But indeed the point is what happens in the long run: if you look above 
> mine is still better indented... :)  But of course it is not indentation 
> per se the problem: for example 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...

> not a 5 liner...  Anyway, I also truly believe there is no point in 
> belabouring the point: it's the overall picture that one must get to see.

-Julio