Re: [Bug] __wait_status_to_int() is expected to be a macro
On Aug 24 10:26, Eric Blake wrote: > On 08/24/2018 04:06 AM, Corinna Vinschen wrote: > > > > Apologies for reviving an old thread, but I ran into the same problem > > > today. > > > Is there any chance we could have a macro-only '__wait_status_to_int' in > > > Cygwin 2.11.0, please? > > > > Here's the glibc approach: > > > > https://sourceware.org/git/?p=glibc.git;a=commit;h=b49ab5f4503f36dcbf43f821f817da66b2931fe6 > > > > So glibc/Linux doesn't provide `union wait' at all since 2016. > > > > I'm inclined to do the same. Thoughts? > > Makes sense to me. It's a non-portable type, and if glibc is no longer > providing union wait and no one is complaining about their stuff not > compiling there, then it's hard to argue what Cygwin apps need the type to > stick around. Right, thanks for your feedback. Patch pushed. union wait is history. I'll uploaded a new developer snapshot to https://cygwin.com/snapshots/ and will create a new test release shortly. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [Bug] __wait_status_to_int() is expected to be a macro
On 08/24/2018 04:06 AM, Corinna Vinschen wrote: Apologies for reviving an old thread, but I ran into the same problem today. Is there any chance we could have a macro-only '__wait_status_to_int' in Cygwin 2.11.0, please? Here's the glibc approach: https://sourceware.org/git/?p=glibc.git;a=commit;h=b49ab5f4503f36dcbf43f821f817da66b2931fe6 So glibc/Linux doesn't provide `union wait' at all since 2016. I'm inclined to do the same. Thoughts? Makes sense to me. It's a non-portable type, and if glibc is no longer providing union wait and no one is complaining about their stuff not compiling there, then it's hard to argue what Cygwin apps need the type to stick around. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org -- 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: [Bug] __wait_status_to_int() is expected to be a macro
On Aug 24 00:13, David Stacey wrote: > On 12/06/18 12:45, Eric Blake wrote: > > On 06/12/2018 03:48 AM, Corinna Vinschen wrote: > > > On Jun 8 12:43, Eric Blake wrote: > > > > On 06/08/2018 12:26 PM, Hans-Bernhard Bröker wrote: > > > > > Am 08.06.2018 um 17:16 schrieb Denis Nikiforov: > > > > > > /usr/include/boost/process/detail/posix/is_running.hpp:18:1: error: > > > > > > non-constant condition for static assertion > > > > > > static_assert(!WIFEXITED(still_active), "Internal Error"); > > > > > > ^ > > > > > > > > > > > > __wait_status_to_int must be a macros but it's redefined > > > > > > as a function. > > > > > > But, assuming I'm completely off-track above and a macro is really > > > desired: > > > > > > Defining __wait_status_to_int as function is C++-specific. I don't > > > think > > > this is really required. A quick test implies the C macro definition in > > > sys/wait.h is sufficent for C++ as well. > > > > Yes, I think you're right on that front. > > Apologies for reviving an old thread, but I ran into the same problem today. > Is there any chance we could have a macro-only '__wait_status_to_int' in > Cygwin 2.11.0, please? Here's the glibc approach: https://sourceware.org/git/?p=glibc.git;a=commit;h=b49ab5f4503f36dcbf43f821f817da66b2931fe6 So glibc/Linux doesn't provide `union wait' at all since 2016. I'm inclined to do the same. Thoughts? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [Bug] __wait_status_to_int() is expected to be a macro
On 12/06/18 12:45, Eric Blake wrote: On 06/12/2018 03:48 AM, Corinna Vinschen wrote: On Jun 8 12:43, Eric Blake wrote: On 06/08/2018 12:26 PM, Hans-Bernhard Bröker wrote: Am 08.06.2018 um 17:16 schrieb Denis Nikiforov: /usr/include/boost/process/detail/posix/is_running.hpp:18:1: error: non-constant condition for static assertion static_assert(!WIFEXITED(still_active), "Internal Error"); ^ __wait_status_to_int must be a macros but it's redefined as a function. But, assuming I'm completely off-track above and a macro is really desired: Defining __wait_status_to_int as function is C++-specific. I don't think this is really required. A quick test implies the C macro definition in sys/wait.h is sufficent for C++ as well. Yes, I think you're right on that front. Apologies for reviving an old thread, but I ran into the same problem today. Is there any chance we could have a macro-only '__wait_status_to_int' in Cygwin 2.11.0, please? Many thanks in advance, Dave. -- 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: [Bug] __wait_status_to_int() is expected to be a macro
On 06/12/2018 03:48 AM, Corinna Vinschen wrote: On Jun 8 12:43, Eric Blake wrote: On 06/08/2018 12:26 PM, Hans-Bernhard Bröker wrote: Am 08.06.2018 um 17:16 schrieb Denis Nikiforov: /usr/include/boost/process/detail/posix/is_running.hpp:18:1: error: non-constant condition for static assertion static_assert(!WIFEXITED(still_active), "Internal Error"); ^ __wait_status_to_int must be a macros but it's redefined as a function. I don't know the surrounding code, but in how for does this make sense at all? This expression is never static, afaics: int status; wait (); WIFEXITED(status); That's the typical use. But the context in boost's is_running.hpp is: constexpr int still_active = 0x7F; static_assert(!WIFEXITED(still_active), "Internal Error"); which means boost _is_ trying to assert that a particular process status value will be interpreted as a non-exited status. But that in itself is non-portable: process status has traditionally been 16 bits, but there are some platforms which do '(abnormal<<8)|normal' and some platforms which do '(normal<<8)|abnormal' when combining the 8 bits of normal exit status with the 8 bits for reporting death by signal. You _cannot_ guarantee whether the constant value 0x7F is the 'normal' status or the 'abnormal' status half of the wait() result. That's WHY the WIFEXITED() macro and friends exist - to abstract away _which_ bits are important to which situation. So anyone ever trying to assert that a _particular_ value has a given meaning, without using the macros (other than the special case of '0' happening to work for WIFEXITED() on all platforms, regardless of which way the two halves are pasted together), is buggy. What's more, I can't see any other use of 'still_active' in is_running.hpp, nor any other use of process status that does NOT use the portable WIFEXITED() macro and friends, so I have no idea why boost is bothering to make a non-portable static assertion in the first place. But as I don't use boost on a regular basis, I'm not in the best position to file this as an upstream bug to that project. The sense of the above expression with a constant "still_active" is somehow beyond me. And this has nothing to do with macro vs. inline function, nor ... Yeah, if it were a runtime value, then it makes no sense; the fact that boost really is trying to do a static assertion on a compile-time constant is why compilation failed, but that's because boost is being stupid for doing something that is not portable. But, assuming I'm completely off-track above and a macro is really desired: Defining __wait_status_to_int as function is C++-specific. I don't think this is really required. A quick test implies the C macro definition in sys/wait.h is sufficent for C++ as well. Yes, I think you're right on that front. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org -- 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: [Bug] __wait_status_to_int() is expected to be a macro
On Jun 8 12:43, Eric Blake wrote: > On 06/08/2018 12:26 PM, Hans-Bernhard Bröker wrote: > > Am 08.06.2018 um 17:16 schrieb Denis Nikiforov: > > > /usr/include/boost/process/detail/posix/is_running.hpp:18:1: error: > > > non-constant condition for static assertion > > > static_assert(!WIFEXITED(still_active), "Internal Error"); > > > ^ > > > > > > __wait_status_to_int must be a macros but it's redefined as a function. I don't know the surrounding code, but in how for does this make sense at all? This expression is never static, afaics: int status; wait (); WIFEXITED(status); The sense of the above expression with a constant "still_active" is somehow beyond me. And this has nothing to do with macro vs. inline function, nor ... > > It must? Says who, based on what standard document? > > > > For starters, nobody gets to make any such claims about > > __wait_status_to_int(), because that's an internal implementation detail > > of Cygwin. If at all, such a claim might be made about WIFEXITED(), > > which is a POSIX standard element. But POSIX makes no such requirement, > > as far as I could see on short examination. > > POSIX requires: > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_wait.h.html#tag_13_71 > > "The header shall define the following macros for analysis of > process status values: > > WEXITSTATUS > Return exit status. > WIFCONTINUED > [XSI] [Option Start] True if child has been continued. [Option End] > WIFEXITED > True if child exited normally. > ..." > > and: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/waitpid.html > > "Regardless of its value, this information may be interpreted using the > following macros, which are defined in and evaluate to integral > expressions; the stat_val argument is the integer value pointed to by > stat_loc. > > WIFEXITED(stat_val) > Evaluates to a non-zero value if status was returned for a child process > that terminated normally. > WEXITSTATUS(stat_val)" > > > Nothing in that wording requires WIFEXITED(foo) to be a compile-time > constant if foo is also a compile-time constant, so on that grounds, Boost > is buggy for trying to assume that WIFEXITED(constant) can be used in a > static_assert(). On the other hand, the implementation of WIFEXITED() is > more like Linux if it DOES result in a compile-time constant when used on a > compile-time constant argument; so in that regards, it would ALSO be worth > patching Cygwin, whether or not the Boost portability bug is fixed. ...with Cygwin vs. Linux. But, assuming I'm completely off-track above and a macro is really desired: Defining __wait_status_to_int as function is C++-specific. I don't think this is really required. A quick test implies the C macro definition in sys/wait.h is sufficent for C++ as well. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [Bug] __wait_status_to_int() is expected to be a macro
On 06/08/2018 12:26 PM, Hans-Bernhard Bröker wrote: Am 08.06.2018 um 17:16 schrieb Denis Nikiforov: /usr/include/boost/process/detail/posix/is_running.hpp:18:1: error: non-constant condition for static assertion static_assert(!WIFEXITED(still_active), "Internal Error"); ^ __wait_status_to_int must be a macros but it's redefined as a function. It must? Says who, based on what standard document? For starters, nobody gets to make any such claims about __wait_status_to_int(), because that's an internal implementation detail of Cygwin. If at all, such a claim might be made about WIFEXITED(), which is a POSIX standard element. But POSIX makes no such requirement, as far as I could see on short examination. POSIX requires: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_wait.h.html#tag_13_71 "The header shall define the following macros for analysis of process status values: WEXITSTATUS Return exit status. WIFCONTINUED [XSI] [Option Start] True if child has been continued. [Option End] WIFEXITED True if child exited normally. ..." and: http://pubs.opengroup.org/onlinepubs/9699919799/functions/waitpid.html "Regardless of its value, this information may be interpreted using the following macros, which are defined in and evaluate to integral expressions; the stat_val argument is the integer value pointed to by stat_loc. WIFEXITED(stat_val) Evaluates to a non-zero value if status was returned for a child process that terminated normally. WEXITSTATUS(stat_val)" Nothing in that wording requires WIFEXITED(foo) to be a compile-time constant if foo is also a compile-time constant, so on that grounds, Boost is buggy for trying to assume that WIFEXITED(constant) can be used in a static_assert(). On the other hand, the implementation of WIFEXITED() is more like Linux if it DOES result in a compile-time constant when used on a compile-time constant argument; so in that regards, it would ALSO be worth patching Cygwin, whether or not the Boost portability bug is fixed. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org -- 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: [Bug] __wait_status_to_int() is expected to be a macro
Am 08.06.2018 um 17:16 schrieb Denis Nikiforov: /usr/include/boost/process/detail/posix/is_running.hpp:18:1: error: non-constant condition for static assertion static_assert(!WIFEXITED(still_active), "Internal Error"); ^ __wait_status_to_int must be a macros but it's redefined as a function. It must? Says who, based on what standard document? For starters, nobody gets to make any such claims about __wait_status_to_int(), because that's an internal implementation detail of Cygwin. If at all, such a claim might be made about WIFEXITED(), which is a POSIX standard element. But POSIX makes no such requirement, as far as I could see on short examination. -- 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
[Bug] __wait_status_to_int() is expected to be a macro
Hi
I'm trying to compile a very simple program:
#include
int main() { }
And I get the following error:
In file included from /usr/include/boost/process/detail/child_decl.hpp:31:0,
from /usr/include/boost/process/child.hpp:21,
from /usr/include/boost/process/async_system.hpp:22,
from /usr/include/boost/process.hpp:24,
from bp.cpp:2:
/usr/include/boost/process/detail/posix/is_running.hpp:18:1: error:
non-constant condition for static assertion
static_assert(!WIFEXITED(still_active), "Internal Error");
^
In file included from /usr/include/cygwin/stdlib.h:13:0,
from /usr/include/stdlib.h:26,
from
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/include/c++/cstdlib:75,
from
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/include/c++/ext/string_conversions.h:41,
from
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/include/c++/bits/basic_string.h:6349,
from
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/include/c++/string:52,
from
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/include/c++/stdexcept:39,
from
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/include/c++/system_error:41,
from /usr/include/boost/process/detail/config.hpp:21,
from /usr/include/boost/process/detail/basic_cmd.hpp:10,
from /usr/include/boost/process/args.hpp:33,
from /usr/include/boost/process.hpp:22,
from bp.cpp:2:
/usr/include/boost/process/detail/posix/is_running.hpp:18:16: error: call
to non-constexpr function 'int __wait_status_to_int(int)'
static_assert(!WIFEXITED(still_active), "Internal Error");
^
As people suggested:
https://stackoverflow.com/questions/50760411/boostprocess-doesnt-work-in-cygwin
it's a bug in /usr/include/sys/wait.h
__wait_status_to_int must be a macros but it's redefined as a function.
--
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
