[libvirt] [PATCH] Cygwin's GCC doesn't like this .sa_handler initialization for some reason

[Matthias Bolte]

2010/4/26 Eric Blake <eblake at redhat.com>:
> On 04/26/2010 01:20 PM, Matthias Bolte wrote:
>>> ACK.  By the way, the "for some reason" boils down to how sa_handler is
>>> declared in <signal.h> on the two platforms.  On cygwin, sa_handler
>>> happens to be a member of an anonymous union (exploiting a gcc
>>> extension); whereas on Linux, it is a macro that accesses a member of a
>>> named union.  If I read POSIX correctly, both behaviors for the
>>> declaration of sa_handler are permitted.  But dotted assignment only
>>> works in the case of a named union.  Whether it is a gcc bug that you
>>> can't use dotted assignment to access a member of an anonymous union, or
>>> a cygwin bug for having a header that does not allow compilation like
>>> Linux (when cygwin's stated goal is to be Linux-compatible) is debatable.
>
> GCC bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
> But cygwin will (probably) be changing to match Linux anyways:
> http://cygwin.com/ml/cygwin/2010-04/msg00947.html
>
>>>
>>> By the way, this use of memset() to initialize action_stop assumes that
>>> the null pointer is all 0 bits (which is probably okay for all platforms
>>> that libvirt will ever run on).  There is currently a discussion on
>>> gnulib on the fact that to be portable to C99, where a null pointer
>>> might not be all 0 bits, you would instead have to use the more
>>> drawn-out sequence:
>>
>> You say null pointer, but where's the pointer in this example?
>
> As an app writer, you have no idea what struct sigaction includes.  You
> know what POSIX requires that it contains (sa_flags is integral,
> sa_handler _is_ a pointer but we happen to be initializing it, and
> sa_sigaction is a pointer but is allowed to overlap with sa_handler),
> but even then, you don't know is whether sa_mask is a pointer (POSIX
> allows that, even though it is integral on Linux).  Then the fact
> remains that you don't know whether the implementation has other fields
> as extensions (on Linux, sa_restorer is an extension, and _is_ a
> pointer; fortunately, Linux only runs on hardware where the null pointer
> is all 0 bits).  Therefore, a strictly C99-compliant app must rely on
> compiler initialization to ensure that all contained pointers are
> initialized to their proper bit value, which might not be all 0s on
> weird architectures; the runtime initialization to all 0-bits using
> memset() would assign invalid values to any such pointer contained in
> the struct.
>

Ah, okay. I didn't get that you referred to the struct members. Now I
understand what you meant, thanks for the detailed explanation.

Matthias