I think Richard Tobin was right when he said...
"Since when were the str* functions supposed to handle NULL?"
I shouldn't be trying to handle null pointers.
That's debatable. The standard str* functions aren't required to do
anything sensible with null arguments (whether the actual parameter
is NULL or any other form of a null pointer value), but that doesn't
mean you must refrain from doing so as well. There may be justifi-
cations that apply to the standard functions (such as pre-standard
implementations and implementation-specific performance tricks) which
don't apply to yours.
All the functions *I* write which take a pointer parameter (except
for a very few special cases) handle null pointers in some fashion,
either by explicitly permitting them in the interface or by returning
an error.
For a function like your "strcasecmp" (note that this name is
reserved to the implementation, and you should not use it), I can see
a few possibilities. One already suggested is to treat null pointers
as if they were pointers to empty strings. A small variation on that
is to consider null pointers equal, but less than any string,
including an empty string. Another is to treat them similarly to
NaNs: null pointers never compare equal to anything, including null
pointers, for the purpose of your function. You'll have to decide
what nonzero value to return in that case, of course. (Since you
have int as the return type, you might want to use something like
INT_MAX as the return value, to distinguish it from likely values for
any legitimate comparison.)
Variations on this topic have been rehashed many times over the years
here, and there are those who feel that violating the interface of a
user-defined function ought to stop a program in its tracks. Even if
I agreed (and I generally do not, for programs of any complexity), I
wouldn't rely on undefined behavior to do that - because, being
undefined, it can't be trusted to do so. If you want to abort the
program if strcasecmp gets a null pointer, that's what abort() is
for.
