Garrett D'Amore wrote: > So, I'm curious, do we have something like a hitlist somewhere of such > ill-behaved applications? (And, correspondingly, a list of those > applications or libraries whose maintainers have declared that they are > not interested in fixing this behavior?)
No and having such a list is pointless. Some of the cases are in things that are currently in Solaris/OpenSolaris (the GNOME examples) but others are in things that aren't and might never be. It is just the state of the world. > My fear is that by masking coding problems like this, we wind up with > worse problems, which are harder to debug, later, and that we wind up > "encouraging" sloppy coding practice rather than working with developers > to fix the busted behavior. That IMO is a silly stance. Every other UNIX platform that still matters (Linux and all other GNU libc systems, FreeBSD, NetBSD, OpenBSD, AIX, HP-UX) all behave the way this case proposes and without any debug traps. > Is the next step really to start checking for null arguments to other > string functions? What about null pointers passed to other library > routines, such as free(), qsort(), bsearch()? Not this case it isn't and I have no such plans. This case is about fixing the pain that OpenSolaris users feel when attempting to build and/or run stuff outside of OpenSolaris. It is a about helping OpenSolaris grow by allowing us to ship those programs wihtout having huge arguments with the upstream community that frankly we have near zero chance of winning in many cases. I'm done with justifying this and discussing it we are just going around in circles covering stuff that was in the original proposal. Either derail or let this finish. -- Darren J Moffat
