>Perhaps another way to look at this issue is that the libc library is >at fault for dereferencing t he NULL pointer in printf. There is no >need for it do dereference the pointer, as it can (and shou ld) check >for NULL first.
No, that is not a correct way of looking at it at all. The only valid way of looking at it is by looking at what the relevant standards have to say and they are unequivoval. The %s argument to sprintf requires passing in a pointer to the first element of an array of character type. NULL is NOT a pointer to the first element of an array of character type and printf is completely within its rights to try to dereference it. NULL, as we know, shall not compare equal to the pointer of any object. >However dereferencing NULL SHOULD crash, and the [EMAIL PROTECTED] library >prevents >this. Thus the [EMAIL PROTECTED] library is not a solution to the NULL >formatting >problem. Not if you take the C standard into consideration which clearly spells out rules which leave no room for an onterpretation other than the one above: passing NULL to printf as argument to a %s specifier is undefined behaviour. Both crashing and printing something weird as well as formatting the hard drive or running "rm -rf $HOME" are perfectly valid actions of a C implementation. Casper _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
