[Libguestfs] [PATCH v2 1/2] appliance: search all types of appliances for each path separately

[Eric Blake]

On 05/05/2017 12:07 PM, Richard W.M. Jones wrote:
> Eric, what do you think of Pavel's analysis and/or suggested fix
> below?  It seems all too plausible to me unfortunately :-(
> 

>> There NULL is macros which can be defined as 0 or (void*)0, again in
>> accordance with c99:

C99 permits:
#define NULL 0

but POSIX does not.  POSIX _requires_

#define NULL ((void*)0)

or the equivalent, so that NULL is properly typed as a pointer to void
in ALL cases (rather than the weaker C99 solution of letting the integer
zero constant leak), in part _because_ of the commonality of passing
NULL through varargs functions.


>>
>> In practice, this means that if NULL is defined as integer and we have
>> 64 bit architecture, then here as the last argument - 4 bytes are
>> written on the stack:
>> dir_contains_files (g, path,
>>                     "README.fixed", "kernel", "initrd", "root", NULL);
>>
>> But va_arg() will read 8 bytes:
>> 	while ((file = va_arg (args, const char *)) != NULL) {
>>
>> I don't know how real can be the conditions to reproduce this, I mean
>> the standard header where #define NULL (0), but as an extra precaution
>> I can offer a patch (attached).

Not worth worrying about in practice.  All modern libc define NULL
according to POSIX rules, rather than the weaker C99 rules.  And gnulib
guarantees the stronger definition of NULL.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20170505/9ed7b39d/attachment.sig>