Messages in this thread |  | | Date | Tue, 24 Sep 1996 8:27:11 -0500 | From | "Ray Van Tassle-CRV004" <> | Subject | RE: 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
|  |