From: steve DOT greenland AT aspentech DOT com (Steve Greenland) Subject: RE: strlen on a NULL 14 May 1998 06:35:10 -0700 Message-ID: Mime-Version: 1.0 Content-Type: text/plain To: gnu-win32 AT cygnus DOT com > From: Valery Fine [mailto:fine AT bnl DOT gov] > 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 "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 "gnu-win32-request AT cygnus DOT com" with one line of text: "help".