stailey@iris613.gsfc.nasa.gov (Ken Stailey) (02/19/90)
The strlen distributed with ST 1.5.0 will core dump if it is passed a NULL
pointer. I ran across this when I brought up the nroff clone "ro" on the ST.
You can fix this by putting in an explicit test for mem location zero at
the top i.e.
if (c == (char *)NULL)
return 0;
INET stailey@iris613.gsfc.nasa.gov
UUCP {backbone}!dftsrv!iris613!staileyhenry@utzoo.uucp (Henry Spencer) (02/20/90)
In article <943@dftsrv.gsfc.nasa.gov> stailey@iris613.UUCP (Ken Stailey) writes: >The strlen distributed with ST 1.5.0 will core dump if it is passed a NULL >pointer... All of the string functions will dump core if presented with NULL pointers. Feeding a NULL pointer to one of them is breaking the rules; the problem is in your code, not in the string functions. -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
stailey@iris613.gsfc.nasa.gov (Ken Stailey) (02/20/90)
In article <1990Feb19.173831.7601@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Feeding a NULL pointer to one of them is breaking the rules; the problem >is in your code, not in the string functions. You mean the problem is in the code to "ro". But it was developed under MS-DOS so what do you expect? ====================================================================== INET stailey@iris613.gsfc.nasa.gov UUCP {backbone}!dftsrv!iris613!stailey
UPSYF173%DBIUNI11.BITNET@cunyvm.cuny.edu (Wolfgang Thiel) (02/20/90)
As I understand this is not a strlen bug, but a bug of the program. You cannot test in every lib function for valid parameters, it's the writer of the program who must garantee this.
HENRYM@udel.edu (02/24/90)
>As I understand this is not a strlen bug, but a bug of the program. >You cannot test in every lib function for valid parameters, it's the >writer of the program who must garantee this. Testing a parameter for validity inside a library routine makes a lot more sense than checking the parameters before every call. The overhead of checking the parameter in the library routine is very small, as opposed to the overhead in memory usage to checking each parameter before calling a library routine. -HWM ---------- Henry W. Miller Assistant Systems Manager, Mid Pacific Region U.S. Bureau of Reclamation 2800 Cottage Way MP1100 Sacramento, CA 95825 (916) 978-5108 / FTS 460-5108 Inet: "sanj!sacwms!henrym@caldwr.water.ca.gov" (Vaxcluster) "sanj!sacusr!henrym@caldwr.water.ca.gov" "sanj!sacmgr!henrym@caldwr.water.ca.gov" BITNET: "hmiller@scu" !Warning: This is NOT the same machine as the above cluster. UUCP: "...caldwr!sanj!henrym" "Bad guys abuse public land, good guys save it."
henry@utzoo.uucp (Henry Spencer) (02/25/90)
In article <12043@nigel.udel.EDU> sanj!SACMGR!HENRYM@udel.edu writes: >>As I understand this is not a strlen bug, but a bug of the program. >>You cannot test in every lib function for valid parameters, it's the >>writer of the program who must garantee this. > > Testing a parameter for validity inside a library routine makes >a lot more sense than checking the parameters before every call... This is true, other things being equal... but they usually aren't equal. Most of the time, the caller knows that the parameters are valid and does not *need* to check them. The callee can't tell. -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu