>>> On 10.02.15 at 22:49, <andrew.coop...@citrix.com> wrote:
> On 10/02/2015 21:44, Boris Ostrovsky wrote:
>> If NULL pointer is passed for these specifiers then print '-'
>> or 'd-v-'.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com>
> 
> Instead of special casing each custom format, I would be tempted just to
> put the switch() in an if(arg) conditional, and fall back to the regular
> number for a NULL pointer, or go along the glibc route and print "(NULL)".
> 
> I presume you found this by falling over a NULL  pointer while
> debugging?  I can't see a legitimate reason for formally supporting NULL
> pointers in each context, but crashing is certainly better avoided.

I tend to disagree - lots of functions get passed pointers that
they dereference _assuming_ they're not NULL (or otherwise
invalid). vsprintf() doesn't need to be a special case - it's the
caller's responsibility to ensure it doesn't pass NULL in such
cases.

That said, I wouldn't object to a patch doing what is outlined in
the first paragraph of Andrew's reply above, but extended to
cover pointing anywhere into known bad ranges (i.e. at least
for x86 in particular anywhere below HYPERVISOR_VIRT_START).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Reply via email to