Question

Came across a line in OpenSSL that made me do a double take…

if (!*pos)
  return NULL;
if (!*pos || ((*pos)->flags == FLAGS))
  return blah;

Is there a (performance/security/concurrecy) difference in doing that instead of:

if (!*pos) 
  return NULL;
if (*pos && ((*pos)->flags == FLAGS))
  return blah;

Thanks,
Chenz

Answer 1

Seems like the first line obsoletes the first condition of the second, but it’s still a good practice to leave checks for not-null before dereferencing, in case earlier code is ever removed, or if code that modifies pos (sets it to NULL) is ever placed between these sections. (one significant disadvantage of return in the middle of a function here…)

Other than that, there should be no difference with any optimizing compiler, but the code may convey the idea better: return blah either if *pos is NULL, or if flags are FLAGS; despite earlier condition that singles out pos==NULL, in this place of execution logic may allow it to be NULL as well and perform the return as described instead of skipping this place.

Imagine:

 if (!*pos)
   return NULL;

  /* code added later here */
  if(foo) 
    pos = baz;   // added latter; baz can be NULL
  /* more code... */

 if (!*pos || ((*pos)->flags == FLAGS))
   return blah;

This will still behave correctly, control returned if pos==NULL, only different return.

Any change to the later condition will modify the behavior:

 if (*pos && ((*pos)->flags == FLAGS))
   return blah;
 crash();