[lkml]   [1996]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: z-NULL strings cause "segmenation fault"
> 	.
> if (strcmp(s, t) == 0)
> It seems that if s or t are NULL pointers (as they are when first
> allocated) then I get the fault. According to the MAN page on strcmp, if
> s or t are NULL then they are treated as if they point to NULL-terminated
> string. So I shouldn't have to check for this in my program.

Hmmm. On my SUN (SUNOS 4.1.3) the man page says this:
On the Sun processor, as well as on many other machines, you
can not use a NULL pointer to indicate a null string. A
NULL pointer is an error and results in an abort of the pro-
gram. If you wish to indicate a null string, you must have
a pointer that points to an explicit null string. On some
implementations of the C language on some machines, a NULL
pointer, if dereferenced, would yield a null string; this
highly non-portable trick was used in some programs. Pro-
grammers using a NULL pointer to represent an empty string
should be aware of this portability issue; even on machines
where dereferencing a NULL pointer does not cause an abort
of the program, it does not necessarily yield a null string.

FWIW, I would agree that attempting to use NULL (de-referenced) as
equivalent to an empty string is a Bad Thing (tm), and should be eschewed.
Neither K&R, Borland TCC mention this odd handling of NULL.
This smells like a thoughtless "optimization" of a neophyte. Like my
freshout who thought he'd "improve" the binary search function by making a
range check before doing the binary chop!

At any rate, this special dispensation of "NULL pointer equivalent to a null
string" will NOT work in normal code, nor (I bet) will it work in _other_
library routines (fopen, memcmp, etc.).

-30- Ray

 \ /
  Last update: 2005-03-22 13:38    [W:0.033 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site