Darren J Moffat <Darren.Moffat at sun.com> wrote:
> Garrett D'Amore wrote:
> > Perhaps we can have a compile-time decision, such as done with XPG4
> > versus Sun definitions of things like strtok_r, where broken code is
> > allowed to use -D_ALLOW_BROKEN_NULL_PRINTF or somesuch.
>
> That doesn't solve the problem.
>
> > It would then be a matter of a man page update to allow developers to
> > decide whether they need/want this behavior for their (broken) code.
>
> Developers on Linux and *BSD aren't reading Solaris man pages. The
> whole reason for this case is for making building and running existing
> softwar that works (regardless of what "we" think of the quality issue
> of passing NULL to printf) on other platforms.
>
> That means no environment variables no compile time flags, nothing.
> Just make our libc printf(3C) family not cause a SEGV like everyone
> elses, and do it all the time.
Applications from AT&T SYSvr3 typically did dump core on SunOS-4.x because they
made the assumption that you may access data at address NULL and that NULL
points to "". For this reason many SYSvr3 programs did dump core on SunOS-4.x
when they were still parsing the command line while trying to access
argv[argc].
If you really like to introduce changes that prevent NULL string pointers
from dumping the core in badly written programs, then you will start to change
strcmp(),.... in the next run. Is this really what we like to see on
OpenSolaris?
My private printf implementation prints "(NULL POINTER)" for NULL string
pointers. I am not against this specific change but we should have a plan on
what we like to achive with OpenSolaris and why/how we do things. If the reason
for the change is just buggy software, then rather collect the core dumps from
this software and send stack traces to the authors.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
