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

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

[this was originally raised on the libvirt list]

On 04/25/2010 05:32 AM, Matthias Bolte wrote:
> +    struct sigaction action_stop;
>  
> -    struct sigaction action_stop = {
> -        .sa_handler = stop
> -    };
> +    memset(&action_stop, 0, sizeof action_stop);
> +
> +    action_stop.sa_handler = stop;

This is because on Linux, sa_handler is a macro that expands into an
access of a named member of a named union, whereas on cygwin, sa_handler
is a directly named member of an anonymous union.  Is this a gcc bug, or
should we be changing cygwin/signal.h to follow Linux' lead of using
macros to access named unions to allow source compatibility, since gcc
falls flat at performing named initialization of a member of gcc's
extension of an anonymous union?

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

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

[Dave Korn]

On 26/04/2010 17:45, Eric Blake wrote:
> [this was originally raised on the libvirt list]
> 
> On 04/25/2010 05:32 AM, Matthias Bolte wrote:
>> +    struct sigaction action_stop;
>>  
>> -    struct sigaction action_stop = {
>> -        .sa_handler = stop
>> -    };
>> +    memset(&action_stop, 0, sizeof action_stop);
>> +
>> +    action_stop.sa_handler = stop;
> 
> This is because on Linux, sa_handler is a macro that expands into an
> access of a named member of a named union, whereas on cygwin, sa_handler
> is a directly named member of an anonymous union.  Is this a gcc bug, or
> should we be changing cygwin/signal.h to follow Linux' lead of using
> macros to access named unions to allow source compatibility, since gcc
> falls flat at performing named initialization of a member of gcc's
> extension of an anonymous union?

  This is the long-standing PR10676 :-(

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676

  Given the rate of progress so far, I reckon we should adopt Linux'
workaround.  Hopefully we'll be able to take it back out again someday.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

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

[Corinna Vinschen]

On Apr 26 19:54, Dave Korn wrote:
> On 26/04/2010 17:45, Eric Blake wrote:
> > [this was originally raised on the libvirt list]
> > 
> > On 04/25/2010 05:32 AM, Matthias Bolte wrote:
> >> +    struct sigaction action_stop;
> >>  
> >> -    struct sigaction action_stop = {
> >> -        .sa_handler = stop
> >> -    };
> >> +    memset(&action_stop, 0, sizeof action_stop);
> >> +
> >> +    action_stop.sa_handler = stop;
> > 
> > This is because on Linux, sa_handler is a macro that expands into an
> > access of a named member of a named union, whereas on cygwin, sa_handler
> > is a directly named member of an anonymous union.  Is this a gcc bug, or
> > should we be changing cygwin/signal.h to follow Linux' lead of using
> > macros to access named unions to allow source compatibility, since gcc
> > falls flat at performing named initialization of a member of gcc's
> > extension of an anonymous union?
> 
>   This is the long-standing PR10676 :-(
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
> 
>   Given the rate of progress so far, I reckon we should adopt Linux'
> workaround.  Hopefully we'll be able to take it back out again someday.

Like this?  We are already using analog definitions in the socket header
files.

Index: include/cygwin/signal.h
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/signal.h,v
retrieving revision 1.18
diff -u -p -r1.18 signal.h
--- include/cygwin/signal.h	26 Feb 2010 05:43:50 -0000	1.18
+++ include/cygwin/signal.h	27 Apr 2010 07:23:05 -0000
@@ -194,14 +194,16 @@ typedef void (*_sig_func_ptr)(int);
 
 struct sigaction
 {
-  __extension__ union
+  union
   {
     _sig_func_ptr sa_handler;  		/* SIG_DFL, SIG_IGN, or pointer to a function */
     void  (*sa_sigaction) ( int, siginfo_t *, void * );
-  };
+  } __sighandler_or_action;
   sigset_t sa_mask;
   int sa_flags;
 };
+#define sa_handler	__sighandler_or_action.sa_handler
+#define sa_sigaction	__sighandler_or_action.sa_sigaction
 
 #define SA_NOCLDSTOP 1   		/* Do not generate SIGCHLD when children
 					   stop */

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On 04/27/2010 03:05 AM, Corinna Vinschen wrote:
> Like this?  We are already using analog definitions in the socket header
> files.

Yes, that looks right.

> 
> Index: include/cygwin/signal.h
> ===================================================================
> RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/signal.h,v
> retrieving revision 1.18
> diff -u -p -r1.18 signal.h
> --- include/cygwin/signal.h	26 Feb 2010 05:43:50 -0000	1.18
> +++ include/cygwin/signal.h	27 Apr 2010 07:23:05 -0000
> @@ -194,14 +194,16 @@ typedef void (*_sig_func_ptr)(int);
>  
>  struct sigaction
>  {
> -  __extension__ union
> +  union
>    {
>      _sig_func_ptr sa_handler;  		/* SIG_DFL, SIG_IGN, or pointer to a function */
>      void  (*sa_sigaction) ( int, siginfo_t *, void * );
> -  };
> +  } __sighandler_or_action;
>    sigset_t sa_mask;
>    int sa_flags;
>  };
> +#define sa_handler	__sighandler_or_action.sa_handler
> +#define sa_sigaction	__sighandler_or_action.sa_sigaction

And while we're touching the file, we probably want to do similar
treatment for struct siginfo_t: si_tid, si_overrun, si_sigval, si_value,
si_status, si_utime, si_stime, and si_addr.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

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

[Corinna Vinschen]

On Apr 27 07:58, Eric Blake wrote:
> On 04/27/2010 03:05 AM, Corinna Vinschen wrote:
> > Like this?  We are already using analog definitions in the socket header
> > files.
> 
> Yes, that looks right.
> 
> > 
> > Index: include/cygwin/signal.h
> > ===================================================================
> > RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/signal.h,v
> > retrieving revision 1.18
> > diff -u -p -r1.18 signal.h
> > --- include/cygwin/signal.h	26 Feb 2010 05:43:50 -0000	1.18
> > +++ include/cygwin/signal.h	27 Apr 2010 07:23:05 -0000
> > @@ -194,14 +194,16 @@ typedef void (*_sig_func_ptr)(int);
> >  
> >  struct sigaction
> >  {
> > -  __extension__ union
> > +  union
> >    {
> >      _sig_func_ptr sa_handler;  		/* SIG_DFL, SIG_IGN, or pointer to a function */
> >      void  (*sa_sigaction) ( int, siginfo_t *, void * );
> > -  };
> > +  } __sighandler_or_action;
> >    sigset_t sa_mask;
> >    int sa_flags;
> >  };
> > +#define sa_handler	__sighandler_or_action.sa_handler
> > +#define sa_sigaction	__sighandler_or_action.sa_sigaction
> 
> And while we're touching the file, we probably want to do similar
> treatment for struct siginfo_t: si_tid, si_overrun, si_sigval, si_value,
> si_status, si_utime, si_stime, and si_addr.

Does "we" mean you're going to provide a patch?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

On 04/27/2010 08:06 AM, Corinna Vinschen wrote:
>> And while we're touching the file, we probably want to do similar
>> treatment for struct siginfo_t: si_tid, si_overrun, si_sigval, si_value,
>> si_status, si_utime, si_stime, and si_addr.
> 
> Does "we" mean you're going to provide a patch?

Yes.  Patch coming up shortly.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

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

[Christopher Faylor]

On Tue, Apr 27, 2010 at 08:20:00AM -0600, Eric Blake wrote:
>On 04/27/2010 08:06 AM, Corinna Vinschen wrote:
>>> And while we're touching the file, we probably want to do similar
>>> treatment for struct siginfo_t: si_tid, si_overrun, si_sigval, si_value,
>>> si_status, si_utime, si_stime, and si_addr.
>> 
>> Does "we" mean you're going to provide a patch?
>
>Yes.  Patch coming up shortly.

Wait.

This is not the first time that this kind of issue has come up.  I am extremely
loath to stop using anonymous unions.  So much so in fact, that I don't really
care that this makes us slightly incompatible with Linux.

Polluting the namespace like this is just ugly.  I'd rather not do it.  I'd
rather tell the handful of applications which have problems with this that this
is an incompatibility.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple