>>> 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