* siginfo_t missing member si_band
@ 2013-10-15 14:48 Ryan Johnson
2013-10-15 19:42 ` Christopher Faylor
0 siblings, 1 reply; 12+ messages in thread
From: Ryan Johnson @ 2013-10-15 14:48 UTC (permalink / raw)
To: cygwin
Hi all,
While trying to build python3 for cygwin, I kept encountering the
following error message:
./Modules/signalmodule.c: In function ‘fill_siginfo’:
./Modules/signalmodule.c:745:60: error: ‘siginfo_t’ has no member named
‘si_band’
PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
^
Include/tupleobject.h:62:75: note: in definition of macro
‘PyTuple_SET_ITEM’
#define PyTuple_SET_ITEM(op, i, v) (((PyTupleObject *)(op))->ob_item[i]
= v)
^
./Modules/signalmodule.c:745:5: note: in expansion of macro
‘PyStructSequence_SET_ITEM’
PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
As far as I can tell, siginfo_t::si_band is mandated by POSIX.1-2001,
and required for proper handling of SIGPOLL. The latter seems to
correspond to async I/O with poll(2). I'm pretty sure cygwin doesn't
support async I/O, but shouldn't the struct member at least exist, to
avoid breaking code that assumes its existence? The alternative is to
patch python3 locally so its os.sigwaitinfo function no longer touches
si_band, or to file a bug upstream so that the module's configury tests
for its existence before using it.
Thoughts?
Ryan
--
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] 12+ messages in thread
* Re: siginfo_t missing member si_band
2013-10-15 14:48 siginfo_t missing member si_band Ryan Johnson
@ 2013-10-15 19:42 ` Christopher Faylor
2013-10-15 21:14 ` Ryan Johnson
0 siblings, 1 reply; 12+ messages in thread
From: Christopher Faylor @ 2013-10-15 19:42 UTC (permalink / raw)
To: cygwin
On Tue, Oct 15, 2013 at 10:48:19AM -0400, Ryan Johnson wrote:
>Hi all,
>
>While trying to build python3 for cygwin, I kept encountering the
>following error message:
>
>./Modules/signalmodule.c: In function ?fill_siginfo?:
>./Modules/signalmodule.c:745:60: error: ?siginfo_t? has no member named
>?si_band?
>PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
>^
>Include/tupleobject.h:62:75: note: in definition of macro
>?PyTuple_SET_ITEM?
>#define PyTuple_SET_ITEM(op, i, v) (((PyTupleObject *)(op))->ob_item[i]
>= v)
>^
>./Modules/signalmodule.c:745:5: note: in expansion of macro
>?PyStructSequence_SET_ITEM?
>PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
>
>As far as I can tell, siginfo_t::si_band is mandated by POSIX.1-2001,
>and required for proper handling of SIGPOLL. The latter seems to
>correspond to async I/O with poll(2). I'm pretty sure cygwin doesn't
>support async I/O, but shouldn't the struct member at least exist, to
>avoid breaking code that assumes its existence? The alternative is to
>patch python3 locally so its os.sigwaitinfo function no longer touches
>si_band, or to file a bug upstream so that the module's configury tests
>for its existence before using it.
>
>Thoughts?
Sure. I question the utility of lying in a structure about the
availability of an unimplemented feature. If something is specifically
expecting the structure member to exist it seems like it would be
expecting it to do something.
--
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] 12+ messages in thread
* Re: siginfo_t missing member si_band
2013-10-15 19:42 ` Christopher Faylor
@ 2013-10-15 21:14 ` Ryan Johnson
2013-10-15 22:36 ` Christopher Faylor
0 siblings, 1 reply; 12+ messages in thread
From: Ryan Johnson @ 2013-10-15 21:14 UTC (permalink / raw)
To: cygwin
On 15/10/2013 3:42 PM, Christopher Faylor wrote:
> On Tue, Oct 15, 2013 at 10:48:19AM -0400, Ryan Johnson wrote:
>> Hi all,
>>
>> While trying to build python3 for cygwin, I kept encountering the
>> following error message:
>>
>> ./Modules/signalmodule.c: In function ?fill_siginfo?:
>> ./Modules/signalmodule.c:745:60: error: ?siginfo_t? has no member named
>> ?si_band?
>> PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
>> ^
>> Include/tupleobject.h:62:75: note: in definition of macro
>> ?PyTuple_SET_ITEM?
>> #define PyTuple_SET_ITEM(op, i, v) (((PyTupleObject *)(op))->ob_item[i]
>> = v)
>> ^
>> ./Modules/signalmodule.c:745:5: note: in expansion of macro
>> ?PyStructSequence_SET_ITEM?
>> PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
>>
>> As far as I can tell, siginfo_t::si_band is mandated by POSIX.1-2001,
>> and required for proper handling of SIGPOLL. The latter seems to
>> correspond to async I/O with poll(2). I'm pretty sure cygwin doesn't
>> support async I/O, but shouldn't the struct member at least exist, to
>> avoid breaking code that assumes its existence? The alternative is to
>> patch python3 locally so its os.sigwaitinfo function no longer touches
>> si_band, or to file a bug upstream so that the module's configury tests
>> for its existence before using it.
>>
>> Thoughts?
> Sure. I question the utility of lying in a structure about the
> availability of an unimplemented feature. If something is specifically
> expecting the structure member to exist it seems like it would be
> expecting it to do something.
So that would be a vote for filing a bug upstream with python's FFI
interface to signal handling? Fair enough.
Ryan
--
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] 12+ messages in thread
* Re: siginfo_t missing member si_band
2013-10-15 21:14 ` Ryan Johnson
@ 2013-10-15 22:36 ` Christopher Faylor
2013-10-15 23:15 ` Larry Hall (Cygwin)
2013-10-16 13:17 ` Bengt Larsson
0 siblings, 2 replies; 12+ messages in thread
From: Christopher Faylor @ 2013-10-15 22:36 UTC (permalink / raw)
To: cygwin
On Tue, Oct 15, 2013 at 05:13:57PM -0400, Ryan Johnson wrote:
>On 15/10/2013 3:42 PM, Christopher Faylor wrote:
>> On Tue, Oct 15, 2013 at 10:48:19AM -0400, Ryan Johnson wrote:
>>> Hi all,
>>>
>>> While trying to build python3 for cygwin, I kept encountering the
>>> following error message:
>>>
>>> ./Modules/signalmodule.c: In function ?fill_siginfo?:
>>> ./Modules/signalmodule.c:745:60: error: ?siginfo_t? has no member named
>>> ?si_band?
>>> PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
>>> ^
>>> Include/tupleobject.h:62:75: note: in definition of macro
>>> ?PyTuple_SET_ITEM?
>>> #define PyTuple_SET_ITEM(op, i, v) (((PyTupleObject *)(op))->ob_item[i]
>>> = v)
>>> ^
>>> ./Modules/signalmodule.c:745:5: note: in expansion of macro
>>> ?PyStructSequence_SET_ITEM?
>>> PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
>>>
>>> As far as I can tell, siginfo_t::si_band is mandated by POSIX.1-2001,
>>> and required for proper handling of SIGPOLL. The latter seems to
>>> correspond to async I/O with poll(2). I'm pretty sure cygwin doesn't
>>> support async I/O, but shouldn't the struct member at least exist, to
>>> avoid breaking code that assumes its existence? The alternative is to
>>> patch python3 locally so its os.sigwaitinfo function no longer touches
>>> si_band, or to file a bug upstream so that the module's configury tests
>>> for its existence before using it.
>>>
>>> Thoughts?
>> Sure. I question the utility of lying in a structure about the
>> availability of an unimplemented feature. If something is specifically
>> expecting the structure member to exist it seems like it would be
>> expecting it to do something.
>So that would be a vote for filing a bug upstream with python's FFI
>interface to signal handling? Fair enough.
I guess so. In a project that wasn't requestware or wishware it would
be a spur for someone to submit code to Cygwin to implement SIGPOLL and
it's accompanying siginfo_t handling. Unfortunately, Cygwin seems to
be mainly requestware these days.
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] 12+ messages in thread
* Re: siginfo_t missing member si_band
2013-10-15 22:36 ` Christopher Faylor
@ 2013-10-15 23:15 ` Larry Hall (Cygwin)
2013-10-15 23:16 ` Warren Young
2013-10-16 13:17 ` Bengt Larsson
1 sibling, 1 reply; 12+ messages in thread
From: Larry Hall (Cygwin) @ 2013-10-15 23:15 UTC (permalink / raw)
To: cygwin
On 10/15/2013 6:36 PM, Christopher Faylor wrote:
> On Tue, Oct 15, 2013 at 05:13:57PM -0400, Ryan Johnson wrote:
>> On 15/10/2013 3:42 PM, Christopher Faylor wrote:
>>> On Tue, Oct 15, 2013 at 10:48:19AM -0400, Ryan Johnson wrote:
>>>> Hi all,
>>>>
>>>> While trying to build python3 for cygwin, I kept encountering the
>>>> following error message:
>>>>
>>>> ./Modules/signalmodule.c: In function ?fill_siginfo?:
>>>> ./Modules/signalmodule.c:745:60: error: ?siginfo_t? has no member named
>>>> ?si_band?
>>>> PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
>>>> ^
>>>> Include/tupleobject.h:62:75: note: in definition of macro
>>>> ?PyTuple_SET_ITEM?
>>>> #define PyTuple_SET_ITEM(op, i, v) (((PyTupleObject *)(op))->ob_item[i]
>>>> = v)
>>>> ^
>>>> ./Modules/signalmodule.c:745:5: note: in expansion of macro
>>>> ?PyStructSequence_SET_ITEM?
>>>> PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
>>>>
>>>> As far as I can tell, siginfo_t::si_band is mandated by POSIX.1-2001,
>>>> and required for proper handling of SIGPOLL. The latter seems to
>>>> correspond to async I/O with poll(2). I'm pretty sure cygwin doesn't
>>>> support async I/O, but shouldn't the struct member at least exist, to
>>>> avoid breaking code that assumes its existence? The alternative is to
>>>> patch python3 locally so its os.sigwaitinfo function no longer touches
>>>> si_band, or to file a bug upstream so that the module's configury tests
>>>> for its existence before using it.
>>>>
>>>> Thoughts?
>>> Sure. I question the utility of lying in a structure about the
>>> availability of an unimplemented feature. If something is specifically
>>> expecting the structure member to exist it seems like it would be
>>> expecting it to do something.
>> So that would be a vote for filing a bug upstream with python's FFI
>> interface to signal handling? Fair enough.
>
> I guess so. In a project that wasn't requestware or wishware it would
> be a spur for someone to submit code to Cygwin to implement SIGPOLL and
> it's accompanying siginfo_t handling. Unfortunately, Cygwin seems to
> be mainly requestware these days.
Any chance of getting a Cygwin implementation of a coffee-maker then? ;-)
--
Larry
_____________________________________________________________________
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?
--
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] 12+ messages in thread
* Re: siginfo_t missing member si_band
2013-10-15 23:15 ` Larry Hall (Cygwin)
@ 2013-10-15 23:16 ` Warren Young
2013-10-16 7:59 ` Corinna Vinschen
0 siblings, 1 reply; 12+ messages in thread
From: Warren Young @ 2013-10-15 23:16 UTC (permalink / raw)
To: cygwin
On 10/15/2013 17:14, Larry Hall (Cygwin) wrote:
> Any chance of getting a Cygwin implementation of a coffee-maker then? ;-)
Well, it *is* a standard. RFC 2324: http://tools.ietf.org/html/rfc2324
--
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] 12+ messages in thread
* Re: siginfo_t missing member si_band
2013-10-15 23:16 ` Warren Young
@ 2013-10-16 7:59 ` Corinna Vinschen
2013-10-16 21:27 ` Christopher Faylor
0 siblings, 1 reply; 12+ messages in thread
From: Corinna Vinschen @ 2013-10-16 7:59 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
On Oct 15 17:16, Warren Young wrote:
> On 10/15/2013 17:14, Larry Hall (Cygwin) wrote:
> >Any chance of getting a Cygwin implementation of a coffee-maker then? ;-)
>
> Well, it *is* a standard. RFC 2324: http://tools.ietf.org/html/rfc2324
I'd expect there's an OSS library somewhere around which implements it.
Or maybe we could just grab the BSD code...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: siginfo_t missing member si_band
2013-10-16 7:59 ` Corinna Vinschen
@ 2013-10-16 21:27 ` Christopher Faylor
2013-10-17 3:46 ` Ryan Johnson
0 siblings, 1 reply; 12+ messages in thread
From: Christopher Faylor @ 2013-10-16 21:27 UTC (permalink / raw)
To: cygwin
On Wed, Oct 16, 2013 at 09:59:25AM +0200, Corinna Vinschen wrote:
>On Oct 15 17:16, Warren Young wrote:
>> On 10/15/2013 17:14, Larry Hall (Cygwin) wrote:
>> >Any chance of getting a Cygwin implementation of a coffee-maker then? ;-)
>>
>> Well, it *is* a standard. RFC 2324: http://tools.ietf.org/html/rfc2324
>
>I'd expect there's an OSS library somewhere around which implements it.
>Or maybe we could just grab the BSD code...
I don't see how SIGPOLL could be implemented by copying BSD code. It
would have to rely on modifying the fhandler code.
--
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] 12+ messages in thread
* Re: siginfo_t missing member si_band
2013-10-16 21:27 ` Christopher Faylor
@ 2013-10-17 3:46 ` Ryan Johnson
2013-10-17 8:48 ` Corinna Vinschen
0 siblings, 1 reply; 12+ messages in thread
From: Ryan Johnson @ 2013-10-17 3:46 UTC (permalink / raw)
To: cygwin
On 16/10/2013 5:27 PM, Christopher Faylor wrote:
> On Wed, Oct 16, 2013 at 09:59:25AM +0200, Corinna Vinschen wrote:
>> On Oct 15 17:16, Warren Young wrote:
>>> On 10/15/2013 17:14, Larry Hall (Cygwin) wrote:
>>>> Any chance of getting a Cygwin implementation of a coffee-maker then? ;-)
>>> Well, it *is* a standard. RFC 2324: http://tools.ietf.org/html/rfc2324
>> I'd expect there's an OSS library somewhere around which implements it.
>> Or maybe we could just grab the BSD code...
> I don't see how SIGPOLL could be implemented by copying BSD code. It
> would have to rely on modifying the fhandler code.
It would be fascinating to see the patch that teaches fhandler to make
coffee...
(BTW, that's neither a request nor a wish. Cygwin isn't requestware or
wishware.)
--
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] 12+ messages in thread
* Re: siginfo_t missing member si_band
2013-10-17 3:46 ` Ryan Johnson
@ 2013-10-17 8:48 ` Corinna Vinschen
0 siblings, 0 replies; 12+ messages in thread
From: Corinna Vinschen @ 2013-10-17 8:48 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
On Oct 16 23:46, Ryan Johnson wrote:
> On 16/10/2013 5:27 PM, Christopher Faylor wrote:
> >On Wed, Oct 16, 2013 at 09:59:25AM +0200, Corinna Vinschen wrote:
> >>On Oct 15 17:16, Warren Young wrote:
> >>>On 10/15/2013 17:14, Larry Hall (Cygwin) wrote:
> >>>>Any chance of getting a Cygwin implementation of a coffee-maker then? ;-)
> >>>Well, it *is* a standard. RFC 2324: http://tools.ietf.org/html/rfc2324
> >>I'd expect there's an OSS library somewhere around which implements it.
> >>Or maybe we could just grab the BSD code...
> >I don't see how SIGPOLL could be implemented by copying BSD code. It
> >would have to rely on modifying the fhandler code.
> It would be fascinating to see the patch that teaches fhandler to
> make coffee...
>
> (BTW, that's neither a request nor a wish. Cygwin isn't requestware
> or wishware.)
And, unfortunately, it's not even coffeeware.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: siginfo_t missing member si_band
2013-10-15 22:36 ` Christopher Faylor
2013-10-15 23:15 ` Larry Hall (Cygwin)
@ 2013-10-16 13:17 ` Bengt Larsson
2013-10-16 16:05 ` Corinna Vinschen
1 sibling, 1 reply; 12+ messages in thread
From: Bengt Larsson @ 2013-10-16 13:17 UTC (permalink / raw)
To: cygwin
Christopher Faylor wrote:
>I guess so. In a project that wasn't requestware or wishware it would
>be a spur for someone to submit code to Cygwin to implement SIGPOLL and
>it's accompanying siginfo_t handling. Unfortunately, Cygwin seems to
>be mainly requestware these days.
Is a bug report "requestware"? I actually did look at the malloc code
but I found it very hard to understand.
--
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] 12+ messages in thread
* Re: siginfo_t missing member si_band
2013-10-16 13:17 ` Bengt Larsson
@ 2013-10-16 16:05 ` Corinna Vinschen
0 siblings, 0 replies; 12+ messages in thread
From: Corinna Vinschen @ 2013-10-16 16:05 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 915 bytes --]
On Oct 16 15:17, Bengt Larsson wrote:
> Christopher Faylor wrote:
>
> >I guess so. In a project that wasn't requestware or wishware it would
> >be a spur for someone to submit code to Cygwin to implement SIGPOLL and
> >it's accompanying siginfo_t handling. Unfortunately, Cygwin seems to
> >be mainly requestware these days.
>
> Is a bug report "requestware"? I actually did look at the malloc code
> but I found it very hard to understand.
No, good bugreports with testcases are usually a joy (unless it's in a
part of code the developer hates a lot, but that goes without saying, I
guess). As for the Doug Lea malloc code, I think there aren't so many
people claiming they fully understand the code. Except Doug Lea,
probably.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-10-17 8:48 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-15 14:48 siginfo_t missing member si_band Ryan Johnson
2013-10-15 19:42 ` Christopher Faylor
2013-10-15 21:14 ` Ryan Johnson
2013-10-15 22:36 ` Christopher Faylor
2013-10-15 23:15 ` Larry Hall (Cygwin)
2013-10-15 23:16 ` Warren Young
2013-10-16 7:59 ` Corinna Vinschen
2013-10-16 21:27 ` Christopher Faylor
2013-10-17 3:46 ` Ryan Johnson
2013-10-17 8:48 ` Corinna Vinschen
2013-10-16 13:17 ` Bengt Larsson
2013-10-16 16:05 ` Corinna Vinschen
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).