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

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.