Subject: RE: strlen on a NULL
From: [email-masked] (Steve Greenland)

14 May 1998 06:35:10 -0700
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain
To: [email-masked]

> From: Valery Fine [mailto:[email-masked]]
> Sent: Tuesday, May 12, 1998 12:40 PM
>
> On 12 May 98 at 18:05, Ian Collins wrote:
> > If I do a strlen on a NULL pointer I get a coredump.
> > I have the same code running on a few *other* Unix machines with
> > exhibiting this behaviour. OK, so I could tidy it up, but I wondered
> > is this an oversight or the correct behaviour?
> 
>   This depends of the implementation of str* "family".
> 
>   In general one should NOT assume this "family" does accept ZERO 
> pointer.  (From our experience of supporting 12 diff UNIX platforms, 
> Win 95 /NT (Symantec ,MSVC) it is 50 % / 50 % ).

In general one should read and understand the documentation. In this
particular case, the documentation is the ISO C Standard. The first
two sentences of section 7.1.7 ("Use of library functions") are:

"Each of the following statements applies unless explicitely stated
otherwise in the detailed descriptions that follow. If the argument to
a function has an invalid value (such as a value outside the domain of
the function, or a pointer outside the address space of the program,
or a null pointer), the behavior is undefined."

Since the description of strlen() does not provide an explicit
exception, then strlen(NULL) is undefined behavior, and the
implementation is free to do anything. Calling strlen() with a null
pointer argument is a bug.

To be fair, I realize that not everybody has access to a copy of the
standard (it's not cheap, and not online), but Plauger's _The Standard
C Library_ is only US $30, includes the library section of the
standard. If you're a professional or serious hobbyist C programmer,
you should own a copy. You can also learn a lot by reading comp.std.c
(but *don't* post questions about programming PC serial ports :-)).

Sorry to rant about this, but at least half of the replies have been
incorrect or misleading. I've spent a fair portion of my career
porting C code from one environment to another (PCs, VMS, various
Unices) and way too much of that time was spent tracking and fixing
bugs like this, so I've become very sensitive to just what the
standard promises. Just because something happens to work on one
implementation doesn't mean that it's correct.

Steve

--
Steve Greenland <[email-masked]>
"Why do we have to hide from the police, Daddy?"
"Because we use vi, son. They use emacs." 
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".