Having ported a bunch of code with str==NULL problems, my observation is that the most common situation is the assumption that: str=NULL is treated as str="" Not only in printf (and friends: vprintf...) but also in the str* functions.
The team I was working with at the time didn't want to just link 0 at 0 with the application because we wanted to find out about other uses of bad pointers. So instead, the approach we used was to provide wrappers that allow str=NULL to be treated as str="". It's not hard to do for the str* functions, but is rather tricky for printf because you have to walk the format string in the wrapper. One suggestion I have here would be to provide some sort of "shim" library that these (arguably broken) applications can link with that does the null string ptr substitutions. Maybe the printf internals (doprnt?) could call some function for %s that the "shim" can substitute? Gordon James Carlson wrote: > ???The sad thing here is that it's really the bug-ridden application > code > that mishandles NULL pointers that's of poor quality, so it's not > OpenSolaris's reputation that should be at stake. > > So, with this one under our belts, should we also fix up the str*(3C) > family of functions so that they quietly ignore NULL pointers as well? > An application that's incautious with NULL can't possibly just make > that mistake with printf alone, can it? > > Is NULL the only bad pointer worth caring about? What sorts of bad > pointer checks need to be made so that malfunctioning applications can > continue running without dropping core? How deep does the rabbit hole > go? >
