Date: Fri, 9 Jan 1998 19:46:29 -0800 (PST) From: asami@cs.berkeley.edu (Satoshi Asami) To: tlambert@primenet.com Cc: jamie@itribe.net, jdevale@ece.cmu.edu, hackers@FreeBSD.ORG Subject: Re: FreeBSD Netcards Message-ID: <199801100346.TAA04537@silvia.HIP.Berkeley.EDU> In-Reply-To: <199801092242.PAA00305@usr04.primenet.com> (message from Terry Lambert on Fri, 9 Jan 1998 22:42:55 %2B0000 (GMT))
next in thread | previous in thread | raw e-mail | index | archive | help
* > > Thus when her/his program aborts * > > catastrophically, they debug it, and feel stupid that they did something * > > like pass NULL to atoi (which actually causes an abort in freeBSD). The * > > linux users, on the other hand, can't figure it out, or bitch and whine, * > > and as a result, the system call is fixed to return an error code instead * > > of an abort. Since you have to know about these bugs to fix them, it * > > seems likely that freeBSD users/programmers just do fewer stupid things. More like it's easier to debug a program if you get a seg fault. Run it in gdb, and it will immediately tell you where it died. Go up one function, and you get the place that's passing NULL to atoi(). If atoi() prints and error message but returns anyway, the program may die much later in some other rather obscure place. Note that as far as the user is concerened, there is no difference in functionality if the program is badly written. The program doesn't work if it either (1) doesn't make sure it doesn't pass to NULL (works for both any system) or (2) check the return value of atoi() and do error recovery (works for Linux). Personally, I think one way to do it right is enough. * 1) Map a zero filled page to page zero. This causes the NULL * to be treated, incorrectly, as a NULL valued string instead * of a NULL. A process which is still running can be examined * via /proc for the address space mappings to see if it has * triggered the page 0 mapping. What the bleep is a "NULL valued string"? Are you aware that the so-called NULL pointer (or rather "0 in a pointer context") is not necessarily equal to a bit string of all zero's? (What was that example of this not being true, hmm, was it a PDP-11?) * This is the default behaviour. It is default because of the * large volume of badly written code which depended on the * Null dereference being treated as a NULL valued string, and * the fact that, historically, page zero was mapped and the * magic number was such that, though it was not a NULL valued * string, you were unlikely to get a match between what was at * offset zero to the first occurance of a NULL byte, and whatever * string you were trying to compare with strcmp, etc.. The * "atoi problem" was such that the magic number did not include * a digit before the terminating 0, and thus atoi of NULL returned * zero. Oh, you mean an empty string? Oh, ok. That has nothing to do with NULL though. (And there is no such thing as "NULL byte"...try "null character' instead.) Satsohi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801100346.TAA04537>