Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: Fixing a sample from K&R book using cake static analyser
Date: Mon, 24 Jun 2024 11:53:51 +0100
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <87ikxyobls.fsf@bsb.me.uk>
References: <v53sl1$35qt7$1@dont-email.me> <v558hv$3dskb$1@dont-email.me>
	<20240623034624.135@kylheku.com> <87wmmfq4if.fsf@bsb.me.uk>
	<20240624012527.8bbe16b96f5bfca10feadb5c@gmail.moc>
	<87zfrbnsvv.fsf@bsb.me.uk> <v5aeue$j1nj$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 24 Jun 2024 12:53:52 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2fe2b5b522b691828527b639c59887b1";
	logging-data="950007"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/rCq06nIu/u1RHnOxPCr+drCa5ZgmrNug="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:XRsfogaXBsXmc9aiGP3HJzjSsgo=
	sha1:1Z4ECV4uO+av1NOKAg1XnHyTrLA=
X-BSB-Auth: 1.0856d963d456a1826bed.20240624115351BST.87ikxyobls.fsf@bsb.me.uk
Bytes: 3350

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Mon, 24 Jun 2024 00:25:56 +0100, Ben Bacarisse wrote:
>
>> struct nlist *install(const char *name, const char *defn)
>> {
>>      struct nlist *node = lookup(name);
>>      if (node) {
>>           char *new_defn = strdup(defn);
>>           if (new_defn) {
>>                free(node->defn);
>>                node->defn = new_defn;
>>                return node;
>>           }
>>           else return NULL;
>>      }
>>      else {
>>           struct nlist *new_node = malloc(sizeof *new_node);
>>           char *new_name = strdup(name), *new_defn = strdup(defn);
>>           if (new_node && new_name && new_defn) {
>>                unsigned hashval = hash(name);
>>                new_node->name = new_name;
>>                new_node->defn = new_defn;
>>                new_node->next = hashtab[hashval];
>>                return hashtab[hashval] = new_node;
>>           }
>>           else {
>>                free(new_defn);
>>                free(new_name);
>>                free(new_node);
>>                return NULL;
>>           }
>>      }
>> }
>> 
>> We have four cases:
>> 
>>   node with the name found
>>      new definition allocated new definition not allocated
>>   node with the name not found
>>      new node, name and definition all allocated not all of new node,
>>      name and definition allocated.
>> 
>> We can very simply reason about all of these situations.
>
> Too many different paths in the control flow, though. I think it’s a good 
> idea to minimize that.

Your non-solution has more.  If you fix the bug so it can change
existing entries, your code will have at yet more paths.  In my code the
conditions that apply to all the paths are explicit.  In yours they are
the result unstructured jumps.

I suspect more than ever that you are just trolling.  I don't think you
really believe your posted code is any good -- you are just throwing it
out there to provoke replies.  For one thing, even after a revision it
still has a syntax error.

-- 
Ben.