Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Regarding C code, it's perfectly normal to frequently encounter <code>NULL</code> pointer checks, especially when it comes to function arguments. Personally, I prefer to let the caller resolve the situation, as in:</p> <pre><code>if (p == NULL) { /* maybe do some cleanup and then: */ return errcode; } </code></pre> <p>Public functions, i.e. functions that are part of the API, should always check for <code>NULL</code> pointers. Functions that are designated <code>static</code> may IMO drop those checks. And finally, there's always <code>assert()</code>. Those checks can be suppressed by the compiler flag <code>-NDEBUG</code>. I use <code>assert()</code> in <code>static</code> functions instead of <code>if</code>-statements and in "public" functions for tests that reveal that the caller didn't actually understand the API as a whole, e.g. in a linked list lib:</p> <pre><code>void list_print(list **l) { assert(l != NULL); /* no valid list passed by reference can ever be NULL */ if (*l == NULL) /* but it can be empty */ return; /* print list */ } </code></pre> <p><br> As for your second concern, I can see three options:</p> <p>1) leave everything as it is - after all, it's working.</p> <p>2) introduce new functions:</p> <pre><code>int function_1_2a_3(); int function_1_2b_3(); </code></pre> <p>3) introduce new parametrized functions:</p> <pre><code>int function_1_2_3(int type); </code></pre> <p>Personally, I prefer the latter approach, but that is really just a matter of style. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload