* Re: Cygwin's GCC doesn't like this .sa_handler initialization for some reason
[not found] <20100425113232.GA11541@sbox>
@ 2010-04-26 16:45 ` Eric Blake
2010-04-26 18:35 ` Dave Korn
0 siblings, 1 reply; 7+ messages in thread
From: Eric Blake @ 2010-04-26 16:45 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cygwin's GCC doesn't like this .sa_handler initialization for some reason
2010-04-26 16:45 ` Cygwin's GCC doesn't like this .sa_handler initialization for some reason Eric Blake
@ 2010-04-26 18:35 ` Dave Korn
2010-04-27 9:05 ` Corinna Vinschen
0 siblings, 1 reply; 7+ messages in thread
From: Dave Korn @ 2010-04-26 18:35 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cygwin's GCC doesn't like this .sa_handler initialization for some reason
2010-04-26 18:35 ` Dave Korn
@ 2010-04-27 9:05 ` Corinna Vinschen
2010-04-27 13:58 ` Eric Blake
0 siblings, 1 reply; 7+ messages in thread
From: Corinna Vinschen @ 2010-04-27 9:05 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cygwin's GCC doesn't like this .sa_handler initialization for some reason
2010-04-27 9:05 ` Corinna Vinschen
@ 2010-04-27 13:58 ` Eric Blake
2010-04-27 14:06 ` Corinna Vinschen
0 siblings, 1 reply; 7+ messages in thread
From: Eric Blake @ 2010-04-27 13:58 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cygwin's GCC doesn't like this .sa_handler initialization for some reason
2010-04-27 13:58 ` Eric Blake
@ 2010-04-27 14:06 ` Corinna Vinschen
2010-04-27 14:20 ` Eric Blake
0 siblings, 1 reply; 7+ messages in thread
From: Corinna Vinschen @ 2010-04-27 14:06 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cygwin's GCC doesn't like this .sa_handler initialization for some reason
2010-04-27 14:06 ` Corinna Vinschen
@ 2010-04-27 14:20 ` Eric Blake
2010-04-27 14:54 ` Christopher Faylor
0 siblings, 1 reply; 7+ messages in thread
From: Eric Blake @ 2010-04-27 14:20 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cygwin's GCC doesn't like this .sa_handler initialization for some reason
2010-04-27 14:20 ` Eric Blake
@ 2010-04-27 14:54 ` Christopher Faylor
0 siblings, 0 replies; 7+ messages in thread
From: Christopher Faylor @ 2010-04-27 14:54 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-04-27 14:54 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20100425113232.GA11541@sbox>
2010-04-26 16:45 ` Cygwin's GCC doesn't like this .sa_handler initialization for some reason Eric Blake
2010-04-26 18:35 ` Dave Korn
2010-04-27 9:05 ` Corinna Vinschen
2010-04-27 13:58 ` Eric Blake
2010-04-27 14:06 ` Corinna Vinschen
2010-04-27 14:20 ` Eric Blake
2010-04-27 14:54 ` Christopher Faylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).