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.
>
> 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.
>
The performance and debugging questions are germane I think. I hate to
think that all code in ON that ever does printf() would ever need this
check. :-) Even though individually the results are small, taken
collectively, they add up. (Sort of the software version of "think
globally, act locally" -- I wonder what the additional power consumption
is that this check would cost when aggregated globally.)
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.
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.
But then again, we do have 0 at 0.so.1, right?
It *sounds* like there are two possible decisions before ARC. Either:
1) We continue to declare such behavior "buggy" (results undefined), and
offer workarounds ala 0 at 0.so.1
or
2) We redefine the behavior such that use of NULL here is declared
permissible, and we take the hypothetized hits (if any) to performance
and debuggability.
My leaning is to #1. It seems like we're trying to make bad
applications happy, to satisfy what is probably a small minority of
developers who feel that such use of NULL should be legal (despite
documentation to the contrary) -- and who are unwilling to use a
perfectly reasonable workaround, at a potential cost to the greater set
of well-behaved applications.
It may be that some feel that the options presented here are an
implementation detail. But, I'm not convinced. If we feel so strongly
that we need to offer this behavior *by default* (and as the submitter
proposes, without any alternative to disable it), then we should be
willing to stand by it in the form of a documented promise.
-- Garrett
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080625/0cd7a323/attachment.html>
