StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Does it make sense for someone to call your function with <code>NULL</code> arguments? If not, you should disallow <code>NULL</code> arguments in the <em>contract</em> of your function, e.g. by adding a comment above the declaration saying that it only works on valid, non-<code>NULL</code> arguments. In other words, anyone who uses your function agrees not to give <code>NULL</code> arguments; it's then <em>their</em> responsibility to check against this, not yours.</p> <p>If it does make sense for either or both of the arguments to be <code>NULL</code>, then you need to decide on how your function behaves in that case and implement it thus. In this case you are agreeing to support <code>NULL</code> arguments and do something sensible with them, and therefore it becomes <em>your</em> responsibility to check for this and act accordingly (e.g. <code>if (s1 == NULL)</code>).</p> <p>If you cannot think of any sensible behaviour for <code>NULL</code> arguments, then go with the first option and disallow them altogether. If you do this, then your example call <code>LCS(0,0);</code> is in breach of contract (i.e. passes <code>NULL</code> pointers when the function does not agree to accept them) and should be removed. In a more complex scenario if you are passing the arguments from variables and there is a chance that those variables point to <code>NULL</code>, then you must check before calling <code>LCS</code>, e.g. <code>if (v1 && v2) { LCS(v1,v2); } else { … }</code>.</p> <p>To <em>track</em> possible errors relating to this, you could use <code>assert</code> to check, e.g.:</p> <pre><code>#include <assert.h> char **LCS (char *s1, char *s2) { assert(s1); assert(s2); … } </code></pre> <p>This will cause your program to exit if <code>s1</code> or <code>s2</code> is <code>NULL</code>, unless <code>NDEBUG</code> was defined before including <code>assert.h</code> (in which case the assertions do <em>nothing</em>). So the assertions are a way to check, during development, that the <em>caller</em> is not giving you <code>NULL</code> arguments but it's still an error if they do.</p> <p>As for other invalid pointers, you cannot really even check reliably, e.g. there's no way of knowing whether the caller has a really strange string or if they just passed the wrong address. This, too, is their responsibility to avoid, and <code>LCS</code> should simply assume that the caller is giving you valid data. Of course if you have additional restrictions, e.g. maximum length of the argument strings, then you must make these restrictions clear to the caller (i.e. specify the contract for the function, “this function does X [your responsibility as the implementor of LCS] provided that … [their responsibilities as the user of LCS]”). This applies to <em>all</em> programming, for example the C standard specifies how the language itself and the standard library functions must be used (e.g. cannot divide by zero, argument strings for <code>strcpy</code> cannot overlap, etc).</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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