[BUG] wprintf(L"%s", str) expects str to be wide

[Eric Blake]

On 01/11/2013 10:44 AM, Eric Blake wrote:
> On 01/11/2013 10:02 AM, Craig Howland wrote:
> 
>>      Looks good.  (Good catch on the case 'x', too.)  One very minor
>> thing, to be very gung-ho, should you care to bother:
>>
>> insize = p ? p - arg : prec;    // works
>>
>> insize = (p!=NULL) ? p - arg : prec;    // cleaner
> 
> Pointless waste of typing.
> 
>>
>> (There's tons of the former, of course, and realistically NULL will
>> never be other than 0.)
> 
> Even if NULL is not 0 (which the C standard does allow, after all),

More precisely, NULL (the preprocessor macro) is required by C to be a
constant that evaluates to 0 (and POSIX goes one step further by
requiring that it also have a type of void*), independently of whether
the hardware implementation of a null pointer (the special value
reserved for a pointer that cannot be dereferenced) is the all-0-bit
pattern (most common) or some other pattern.  And compilers are required
to compile code involving null pointers (whether via NULL, via a
constant 0 in the code, or by "zero-initialization" of a struct) to the
actual hardware null pointer value (even in the unlikely case that the
hardware value is not all 0 bits).  Likewise, compilers are required to
compile the conversion of any pointer value to a boolean context by
comparing whether the pointer is a null pointer (whether or not that is
all 0 bits).

But my conclusion remains:

> you are not buying any robustness by adding an explicit
> comparison to NULL.
> 

Only the Java language requires an explicit comparison against null
before converting an object (which is implicitly a pointer) to a boolean
context.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/newlib/attachments/20130111/a67ea413/attachment.sig>