Re: Fixing a sample from K&R book using cake static analyser

Phil Carmody <pc+usenet@asdf.org> writes:

Ben Bacarisse <ben@bsb.me.uk> writes:

Anton Shepelev <anton.txt@gmail.moc> writes:
>

Ben Bacarisse:
>

I don't get why the goto crowd want to complicate it so
much.

>
Will someone post a goto-less that fixes what I perceive as
bugs in the original:
>
  a.  the failure to free() a newly allocated nlist in case
      of a later error,
>
  b.  the failure to free() a newly allocated np->name in
      case of a later error,
>
  c.  the failure to keep np->defn unchaged if the
      allocation of the new defn value failed.
>
And my perception be wrong, let us first establish the
actual bug(s).

>
With the usual trepidation that this is untested (though I did compile
it), I'd write something like:
>
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;
     }

>
That's fine, certainly, but I'm a fan of early fail-and-bail, which
permits the didn't-fail side of the if to remain unindented:
>
      if (node) {
           char *new_defn = strdup(defn);
           if (!new_defn)
               return NULL;
>
           free(node->defn);
           node->defn = new_defn;
           return node;
      }

I deliberately wanted to show that the fully structured "if then else"
way was perfectly clear and simple in this trivial function.  Any
deviation from the easy-to-reason about version can then be assessed to
see if it's clearer?  Does the fail-and-bail here help?  I don't find
one simple indented block to be at all unclear so, to my mind, no it
doesn't.

To be fair, I write a lot of code like you've shown because it's become
a habit.  I think there's a lot of it out there and it's easy enough to
follow so I often do it as well.  But would I change one for the other?
No.

     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;
          }
     }

>
I think I'd deviate a little more on this side, as I don't like doing
the strdups when you know the malloc has failed.

Why?  If it were gathering other key resources, like locks, then I'd
agree, but can it really hurt much?

On the plus side, it gives all the variables free-able values -- either
NULL or a free-able pointer.  That simplifies reasoning about any code
that follows.

Again, early
fail-and-bail applies:
>
     else {
          struct nlist *new_node = malloc(sizeof *new_node);
          if (!new_node)
               return NULL;
         
          char *new_name = strdup(name), *new_defn = strdup(defn);

But one strdup after another might have failed is OK?  I see you address
this below...

          if (!new_name || !new_defn) {
               free(new_defn);
               free(new_name);
               free(new_node);
               return NULL;
          }
         
          unsigned hashval = hash(name);
          new_node->name = new_name;
          new_node->defn = new_defn;
          new_node->next = hashtab[hashval];
          return hashtab[hashval] = new_node;
     }
>
You could split the strdups too, of course, but it's itsy-bitsy.

I don't get why you do one and not the other.  Either it's all
itsy-bitsy or the sequencing is better and should always be preferred.

My main objection to fail-and-bail is a strong preference for expressing
the conditions for successful operation up front.

In all
honesty, I'd probably actually code with gotos, and jump to whichever
bit of cleanup was relevant.

Why?  I've yet to see a goto version of this that is even remotely as
clear as simply writing out what to do in the various cases.

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.

>
I once came across a quirky coding standard that would have split
this into 3 functions. The outermost if/else blocks would
have been two separate helper functions.

That's not quirky; that's perfectly sound advice.  I didn't do it here
because I wanted a direct comparison with all the spaghetti.

struct nlist *install(const char *name, const char *defn)
{
     struct nlist *node = lookup(name);
     if (node)
          return update_node(node, defn);
     else
          return new_node(name, defn);
}

  return node ? update_node(node, defn) : new_node(name, defn);

!

The principle being that every function should do one job, and be
visible in one small screenful. The choice of code structure in each of
the two helper functions is now simplified, as you don't need to
consider anything in the other helper function.

C slightly discourages this in that we need to add declarations or order
the functions "bottom-up".  And, despite using static functions, it's
never clear where else the functions are being used because the smallest
restriction for use of a function is the file.  That might not always
matter much but this example uses a global table, so it would be
important to check that.  The end result is that C programmers tend to
use fewer auxiliary functions than programmers in some other languages.

--
Ben.