That's the Perl school of thought that basically finished Perl as a language for big projects.

It's a great point, and I hated Perl for this very reason. And I'm sure some of it is my defensiveness since this is how I program. But some of it is also my concern that it might signal, during an interview say, that the candidate might not really have a good grasp of pointers. For instance, given the following snippet of code, candidates that didn't really seem to grok pointers wouldn't see that the append() function could not be modifying the list in main():

  struct node {
    int val;
    struct node *next;
  };

  static void append(struct node *list, int val);

  int main(int argc, char **argv)
  {
    struct node *list = NULL;

    append(list, 4);
    ...
  }

And my preference for fixing such an implementation would be to change append to take a pointer-to-a-pointer:

  static void append(struct node **list,  int val);

with an implementation like:

  static void
  append(struct node **list, int val)
  {
    struct node **ppn, *pn;

    if ( (pn = malloc(sizeof *pn)) == NULL) {
        perror("malloc");
        exit(1);
    }

    pn->val = val;
    pn->next = NULL;

    for (ppn = list; *ppn; ppn = &(*ppn)->next)
        /* find tail */;

    *ppn = pn;
  }

and update the call in main() to append(&list, 4).

But as I said, you make a good point, and I agree that your method is the safer of the two options from a maintainability point of view.