Date: Tue, 22 Oct 1996 10:55:07 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: danny@panda.hilink.com.au (Daniel O'Callaghan) Cc: freebsd-hackers@freebsd.org Subject: Re: libc string routines don't check for NULL pointers Message-ID: <199610221755.KAA08239@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.961022180422.548J-100000@panda.hilink.com.au> from "Daniel O'Callaghan" at Oct 22, 96 06:12:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The string comparison (and other) routines in libc don't check for null > pointers being passed. This results in SEGVs if one or both of the > string pointers being passed is NULL. I can see a religious debate here, > but I'm going to raise the issue: Should str*cmp() handle NULL arguments. This has been asked before. The behaviour of a program dereferencing a NULL pointer is undefined. Acting as you suggest is permissible. Acting as BSD currently acts is permissible. The difference is that your implementation requires additional compare overhead to implement your favorite flavor of "undefined". In general, it is considered an error to attempt to dereference NULL pointers. With the current behaviour, programmers are given enough information to correct their code. With the suggested behaviour, it is possible for a cascade failure to occur, where the resulting failure gives little or no clue as to the proximal cause. The historical behavior came because a dereference of a NULL pointer referenced page 0, which has historically been mapped into the user's address space (the first page of the program image). The compare compared the string against the images "magic number" and any code up to the first NULL byte. This generally achieved the expected results because the magic number of the PDP11 (BSD) binaries was less than the normal printable characters you would find in a string. With the advent of internationalization and multibyte encoded strings, this is no longer the case. Consider the change a "built-in purify function" for BSD... it has a lot of value for programmers in general. I assume you are trying to port x.desktop or similar code? The code should be fixed instead of BSD. FreeBSD's behaviour has already resulted in a number of NULL pointer dereference fixes for "elm" and other popular programs. In any event, this whole issue was discussed several years ago when BSD image generation was changed in the linker to cause the image to begin *after* page 0 to trap NULL dereferences. The consensus was that the BSD definition of "undefined" was superior because it flagged non-ANSI compliant C programs. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610221755.KAA08239>