On 04/29/2011 05:18 PM, Pádraig Brady wrote:
>>> I think the case for clearing the bits is a little
>>> stronger than the one for leaving them uninitialized, and would
>>> be even more in favor, it if only this initialization were portable:
>>>
>>> struct sigaction action = {0,};
What would make it non-portable? And should we raise a defect against
POSIX that requests that all types that allow extension fields should be
initializable via {0,} as a way to guarantee values in all extension fields?
> Proposed patch attached.
>
> Subject: [PATCH] manywarnings: add -Wno-missing-field-initializers if needed
>
> * m4/manywarnings.m4 (gl_MANYWARN_ALL_GCC): Add the above
> option if it's needed to allow initialization with { 0, },
> which is the case with GCC before version 4.7
> ---
> ChangeLog | 6 ++++++
> m4/manywarnings.m4 | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 56 insertions(+), 1 deletions(-)
Looks nice from my reading of it. Although for the cache variable
names, should we go with gl_cv_cc_nomfi_supported rather than
gl_cv_nomfi_supported (that is, add cc_ to each of the cache variable
names), to make it clear that the cache variables are all related to CC
characteristics? (Compare how we use cv_func, cv_decl, and other such
namespace designators, and cv_nomfi isn't really a namespace).
--
Eric Blake [email protected] +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
