Don Cragun wrote:
>> Date: Wed, 25 Jun 2008 16:15:58 +0100
>> From: Darren J Moffat <Darren.Moffat at sun.com>
> ... ... ...
>> Basically I see the current behaviour as a long standing regression from
>> SunOS 4.x and was really tempted to not even file an ARC case but just
>> do a bug fix. Lets not over design this or beat it to death in ARC
>> unless there is a standards reason our sound architectural reason why
>> this is the wrong thing do to (and given the behaviour of all the other
>> platforms I'd have a hard time believing that).
>
> There is no standards reason for changing the behavior or leaving it as
> is. The standards all say that passing a null pointer to a *printf()
> function for a format specifier that expects a pointer to a string
> produces undefined results.
Thanks for that.
> I don't know whether you consider it to be a sound architectural reason
> or not, but there was a conscious design decision made when Sun
> negotiated SunOS 5.0 behavior with AT&T not to check for bad code that
> used NULL as a pointer to a string. When libc converts NULL to "", to
> "(null)", or some other arbitrary string instead of dropping core when
> trying to dereference the bad pointer, it slows down all applications
> that use correct pointers, it delays debugging efforts, and it makes it
> more likely that a bad pointer will cause something downstream to
> corrupt other data.
IMO that was the wrong decision given that the additional code in SunOS
4.x was basically this:
static char nullstr = "(null)";
...
if (bp == NULL)
bp = nullstr;
Even a more advanced check that does localisation calls wouldn't impact
"correct" applications because it is just one 'if (bp == NULL)' and
looking that the implementation of printf that isn't going to impact its
performance it has much bigger issues (that are not part of this case!).
--
Darren J Moffat
