Bleadperl breaks MLEHMANN/AnyEvent-7.07.tar.gz on Windows

Perl / perl5

🐪 The Perl programming language

https://dev.perl.org/perl5/

Other

1.9k stars 540 forks source link

Bleadperl breaks MLEHMANN/AnyEvent-7.07.tar.gz on Windows #13764

Closed p5pRT closed 7 years ago

p5pRT commented 10 years ago

Migrated from rt.perl.org#121727 (status was 'resolved')

Searchable as RT121727$

p5pRT commented 10 years ago

From @chorny

Created by @chorny

Tests of AnyEvent fail on Strawberry Perl 5.19.11. This error did not appear on 5.18.2 and earlier.

t/handle/01_readline.t: 1..8 ok 1 - A line was read correctly ok 2 ok 3 - initial lines were read correctly AnyEvent::Handle uncaught error: A non-blocking socket operation could not be completed immediately. at t/handle/01_readline.t line 76. # Looks like you planned 8 tests but ran 3. # Looks like your test exited with 140 just after 3.

Perl Info

``` Flags: category=core severity=low Site configuration information for perl 5.19.11: Configured by strawberry-perl at Tue Apr 22 08:42:15 2014. Summary of my perl5 (revision 5 version 19 subversion 11) configuration: Platform: osname=MSWin32, osvers=6.2, archname=MSWin32-x86-multi-thread-64int uname='Win32 strawberry-perl 5.19.11.1 #1 Tue Apr 22 08:40:30 2014 i386' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define use64bitint=define, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags =' -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fno-strict-aliasing -mms-bitfields', optimize='-s -O2', cppflags='-DWIN32' ccversion='', gccversion='4.8.2', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++', ldflags ='-s -L"C:\strawberry1911\perl\lib\CORE" -L"C:\strawberry1911\c\lib"' libpth=C:\strawberry1911\c\lib C:\strawberry1911\c\i686-w64-mingw32\lib C:\strawberry1911\c\lib\gcc\i686-w64-mingw32\4.8.2 libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 libc=, so=dll, useshrplib=true, libperl=libperl519.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=xs.dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -s -L"C:\strawberry1911\perl\lib\CORE" -L"C:\strawberry1911\c\lib"' @INC for perl 5.19.11: C:/strawberry1911/perl/site/lib C:/strawberry1911/perl/vendor/lib C:/strawberry1911/perl/lib . Environment for perl 5.19.11: HOME (unset) LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=C:\Program Files\Far Manager\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\strawberry1911\c\bin;C:\strawberry1911\perl\site\bin;C:\strawberry1911\perl\bin PERL_BADLANG (unset) PERL_HASH_SEED=0x11111111 SHELL (unset) -- Alexandr Ciornii, http://chorny.net ```

p5pRT commented 10 years ago

From @iabyn

On Thu\, Apr 24\, 2014 at 11:15:49AM -0700\, Alexandr Ciornii wrote:

Tests of AnyEvent fail on Strawberry Perl 5.19.11. This error did not appear on 5.18.2 and earlier.

t/handle/01_readline.t: 1..8 ok 1 - A line was read correctly ok 2 ok 3 - initial lines were read correctly AnyEvent::Handle uncaught error: A non-blocking socket operation could not be completed immediately. at t/handle/01_readline.t line 76. # Looks like you planned 8 tests but ran 3. # Looks like your test exited with 140 just after 3.

Works for me on Linux. I guess this is a Windows-specific issue?

-- Little fly\, thy summer's play my thoughtless hand has terminated with extreme prejudice. (with apologies to William Blake)

p5pRT commented 10 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 10 years ago

From @steve-m-hay

On Fri Apr 25 04:21:47 2014\, davem wrote:

On Thu\, Apr 24\, 2014 at 11:15:49AM -0700\, Alexandr Ciornii wrote:

Tests of AnyEvent fail on Strawberry Perl 5.19.11. This error did not appear on 5.18.2 and earlier.

t/handle/01_readline.t: 1..8 ok 1 - A line was read correctly ok 2 ok 3 - initial lines were read correctly AnyEvent::Handle uncaught error: A non-blocking socket operation could not be completed immediately. at t/handle/01_readline.t line 76. # Looks like you planned 8 tests but ran 3. # Looks like your test exited with 140 just after 3.

Works for me on Linux. I guess this is a Windows-specific issue?

Works for me too on Windows\, using today's blead\, compiled with VC10 and with MinGW-w64-4.8.0 (both default configuration builds\, except in debug mode).

The gcc build test results are attached. Loads of tests shout that my perl is BROKEN (?!)\, but the test in question passes.

p5pRT commented 10 years ago

From @steve-m-hay

C:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0\, 'blib\lib'\, 'blib\arch')" t/*.t t/handle/*.t [14:46:52] t/00_load.t ................ ok 132 ms [14:46:53] t/01_basic.t ............... ok 193 ms [14:46:53] t/02_signals.t ............. skipped: Broken perl detected\, skipping tests. [14:46:53] t/03_child.t ............... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:53] t/04_condvar.t ............. ok 96 ms [14:46:53] t/05_dns.t ................. ok 175 ms [14:46:53] t/06_socket.t .............. ok 98 ms [14:46:53] t/07_io.t .................. ok 199 ms [14:46:53] t/08_idna.t ................ ok 84 ms [14:46:53] t/09_multi.t ............... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:54] t/10_loadall.t ............. ok 163 ms [14:46:54] t/11_io_perl.t ............. ok 125 ms [14:46:54] t/12_io_ioaio.t ............ skipped: AnyEvent::IO::IOAIO not loadable [14:46:54] t/61_fltk_01_basic.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:54] t/61_fltk_02_signals.t ..... skipped: Broken perl detected\, skipping tests. [14:46:54] t/61_fltk_03_child.t ....... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:54] t/61_fltk_04_condvar.t ..... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:54] t/61_fltk_05_dns.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:54] t/61_fltk_07_io.t .......... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:54] t/61_fltk_09_multi.t ....... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:54] t/62_cocoa_01_basic.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:54] t/62_cocoa_02_signals.t .... skipped: Broken perl detected\, skipping tests. [14:46:54] t/62_cocoa_03_child.t ...... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:54] t/62_cocoa_04_condvar.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:54] t/62_cocoa_05_dns.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:54] t/62_cocoa_07_io.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:54] t/62_cocoa_09_multi.t ...... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:54] t/64_glib_01_basic.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:54] t/64_glib_02_signals.t ..... skipped: Broken perl detected\, skipping tests. [14:46:54] t/64_glib_03_child.t ....... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:54] t/64_glib_04_condvar.t ..... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/64_glib_05_dns.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/64_glib_07_io.t .......... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/64_glib_09_multi.t ....... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:55] t/65_event_01_basic.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/65_event_02_signals.t .... skipped: Broken perl detected\, skipping tests. [14:46:55] t/65_event_03_child.t ...... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:55] t/65_event_04_condvar.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/65_event_05_dns.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/65_event_07_io.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/65_event_09_multi.t ...... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:55] t/66_ioasync_01_basic.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/66_ioasync_02_signals.t .. skipped: Broken perl detected\, skipping tests. [14:46:55] t/66_ioasync_03_child.t .... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:55] t/66_ioasync_04_condvar.t .. skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/66_ioasync_05_dns.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/66_ioasync_07_io.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/66_ioasync_09_multi.t .... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:55] t/67_tk_01_basic.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/67_tk_02_signals.t ....... skipped: Broken perl detected\, skipping tests. [14:46:55] t/67_tk_03_child.t ......... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:55] t/67_tk_04_condvar.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/67_tk_05_dns.t ........... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:55] t/67_tk_07_io.t ............ skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:56] t/67_tk_09_multi.t ......... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:56] t/68_poe_01_basic.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:56] t/68_poe_02_signals.t ...... skipped: Broken perl detected\, skipping tests. [14:46:56] t/68_poe_03_child.t ........ skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:56] t/68_poe_04_condvar.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:56] t/68_poe_05_dns.t .......... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:56] t/68_poe_07_io.t ........... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:56] t/68_poe_09_multi.t ........ skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:56] t/69_ev_01_basic.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:56] t/69_ev_02_signals.t ....... skipped: Broken perl detected\, skipping tests. [14:46:56] t/69_ev_03_child.t ......... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:56] t/69_ev_04_condvar.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:56] t/69_ev_05_dns.t ........... skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:56] t/69_ev_07_io.t ............ skipped: PERL_ANYEVENT_LOOP_TESTS not true [14:46:56] t/69_ev_09_multi.t ......... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. [14:46:56] t/80_ssltest.t ............. skipped: no usable Net::SSLeay [14:46:56] t/81_hosts.t ............... ok 270 ms [14:46:57] t/handle/01_readline.t ..... ok 172 ms [14:46:57] t/handle/02_write.t ........ ok 115 ms [14:46:57] t/handle/03_http_req.t ..... skipped: PERL_ANYEVENT_NET_TESTS environment variable not set [14:46:57] t/handle/04_listen.t ....... ok 135 ms [14:46:57] All tests successful. Files=75\, Tests=180\, 5 wallclock secs ( 0.14 usr + 0.03 sys = 0.17 CPU) Result: PASS

p5pRT commented 10 years ago

From @Corion

... I just tested this against the current bleadperl on Windows 7 with the below gcc version\, and the tests in question pass.

This is with an uninstalled AnyEvent and without (say) EV or any other backend available outside of what AnyEvent includes itself.

-max

gcc (gcc-4.6.3 release with patches [build 20121012 by perlmingw.sf.net]) 4.6.3 Copyright (C) 2011 Free Software Foundation\, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

C:\Users\Corion\.cpan\build\AnyEvent-7.07-9P6WmP>perl -V Summary of my perl5 (revision 5 version 19 subversion 12) configuration: Commit id: f001cc46fcf48c9b4c09514d8eeb9c8d9eba6501 Platform: osname=MSWin32\, osvers=6.1\, archname=MSWin32-x64-multi-thread uname='' config_args='undef' hint=recommended\, useposix=true\, d_sigaction=undef useithreads=define\, usemultiplicity=define use64bitint=define\, use64bitall=undef\, uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler: cc='gcc'\, ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_ SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fno-strict-ali asing -mms-bitfields'\, optimize='-s -O2'\, cppflags='-DWIN32' ccversion=''\, gccversion='4.6.3'\, gccosandvers='' intsize=4\, longsize=4\, ptrsize=8\, doublesize=8\, byteorder=12345678 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12 ivtype='long long'\, ivsize=8\, nvtype='double'\, nvsize=8\, Off_t='long long'\, lseeksize=8 alignbytes=8\, prototype=define Linker and Libraries: ld='g++'\, ldflags ='-s -L"c:\perl\lib\CORE" -L"C:\MinGW\lib"' libpth=C:\MinGW\lib libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladva pi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lver sion -lodbc32 -lodbccp32 -lcomctl32 libc=\, so=dll\, useshrplib=true\, libperl=libperl519.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs\, dlext=dll\, d_dlsymun=undef\, ccdlflags=' ' cccdlflags=' '\, lddlflags='-mdll -s -L"c:\perl\lib\CORE" -L"C:\MinGW\lib"'

Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF Built under MSWin32 Compiled at May 8 2014 18:47:51 %ENV: PERL5_CPANPLUS_IS_RUNNING="2108" PERL5_CPAN_IS_RUNNING="2108" @INC: c:/Users/Corion/Projekte/bleadperl/lib .

C:\Users\Corion\.cpan\build\AnyEvent-7.07-9P6WmP>

C:\Users\Corion\.cpan\build\AnyEvent-7.07-9P6WmP>perl Makefile.PL

*** *** The EV module is recommended for even better performance\, unless you *** have to use one of the other adaptors (Event\, Glib\, Tk\, etc.). *** The Async::Interrupt module is highly recommended to efficiently avoid *** race conditions in/with other event loops. *** *** This module does not have ANY dependencies\, even if it might look *** otherwise. If you are building a distribution package or have *** difficulties installing this package due to dependencies\, report this *** to the packager as a bug. *** *** This module is guaranteed to stay 100% pure-perl\, full-featured *** and performant\, even without any of the optional modules. ***

... Detected uninstalled Perl. Trying to continue. Have \users\corion\projekte\bleadp~1\lib Want \perl\lib Generating a dmake-style Makefile Writing Makefile for AnyEvent Writing MYMETA.yml and MYMETA.json

C:\Users\Corion\.cpan\build\AnyEvent-7.07-9P6WmP>perl -v

This is perl 5\, version 19\, subversion 12 (v5.19.12 (v5.19.11-43-gf001cc4)) buil t for MSWin32-x64-multi-thread

Perl may be copied only under the terms of either the Artistic License or the GNU General Public License\, which may be found in the Perl 5 source kit.

Complete documentation for Perl\, including FAQ lists\, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet\, point your browser at http://www.perl.org/\, the Perl Home Page.

C:\Users\Corion\.cpan\build\AnyEvent-7.07-9P6WmP>dmake test cp lib/AnyEvent/Impl/Perl.pm blib\lib/AnyEvent/Impl/Perl.pm cp lib/AnyEvent/IO/IOAIO.pm blib\lib/AnyEvent/IO/IOAIO.pm cp lib/AnyEvent/Impl/Event.pm blib\lib/AnyEvent/Impl/Event.pm cp lib/AnyEvent/IO/Perl.pm blib\lib/AnyEvent/IO/Perl.pm cp lib/AnyEvent/Impl/Glib.pm blib\lib/AnyEvent/Impl/Glib.pm cp lib/AnyEvent.pm blib\lib/AnyEvent.pm cp lib/AnyEvent/Impl/IOAsync.pm blib\lib/AnyEvent/Impl/IOAsync.pm cp lib/AnyEvent/Impl/Tk.pm blib\lib/AnyEvent/Impl/Tk.pm cp lib/AnyEvent/Impl/Qt.pm blib\lib/AnyEvent/Impl/Qt.pm cp lib/AnyEvent/Impl/Irssi.pm blib\lib/AnyEvent/Impl/Irssi.pm cp lib/AnyEvent/IO.pm blib\lib/AnyEvent/IO.pm cp lib/AnyEvent/Impl/POE.pm blib\lib/AnyEvent/Impl/POE.pm cp lib/AnyEvent/Debug.pm blib\lib/AnyEvent/Debug.pm cp lib/AnyEvent/FAQ.pod blib\lib/AnyEvent/FAQ.pod cp lib/AnyEvent/Impl/EventLib.pm blib\lib/AnyEvent/Impl/EventLib.pm cp lib/AnyEvent/Handle.pm blib\lib/AnyEvent/Handle.pm cp lib/AnyEvent/Impl/FLTK.pm blib\lib/AnyEvent/Impl/FLTK.pm cp lib/AnyEvent/DNS.pm blib\lib/AnyEvent/DNS.pm cp lib/AnyEvent/Impl/Cocoa.pm blib\lib/AnyEvent/Impl/Cocoa.pm cp lib/AE.pm blib\lib/AE.pm cp lib/AnyEvent/Impl/EV.pm blib\lib/AnyEvent/Impl/EV.pm cp lib/AnyEvent/Util.pm blib\lib/AnyEvent/Util.pm cp lib/AnyEvent/Loop.pm blib\lib/AnyEvent/Loop.pm cp lib/AnyEvent/TLS.pm blib\lib/AnyEvent/TLS.pm cp lib/AnyEvent/Strict.pm blib\lib/AnyEvent/Strict.pm cp lib/AnyEvent/Util/idna.pl blib\lib/AnyEvent/Util/idna.pl cp lib/AnyEvent/Socket.pm blib\lib/AnyEvent/Socket.pm cp lib/AnyEvent/Intro.pod blib\lib/AnyEvent/Intro.pod cp lib/AnyEvent/constants.pl blib\arch/AnyEvent/constants.pl cp lib/AnyEvent/Util/uts46data.pl blib\lib/AnyEvent/Util/uts46data.pl cp lib/AnyEvent/Log.pm blib\lib/AnyEvent/Log.pm C:\Users\Corion\Projekte\bleadperl\perl.exe "-Ic:/Users/Corion/Projekte/bleadper l/lib" "-Ic:/Users/Corion/Projekte/bleadperl/lib" "-MExtUtils::Command::MM" "-MT est::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0\, 'blib\lib'\, 'blib\arch')" t/*.t t/handle/*.t t/00_load.t ................ ok t/01_basic.t ............... ok t/02_signals.t ............. skipped: Broken perl detected\, skipping tests. t/03_child.t ............... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/04_condvar.t ............. ok t/05_dns.t ................. ok t/06_socket.t .............. ok t/07_io.t .................. ok t/08_idna.t ................ ok t/09_multi.t ............... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/10_loadall.t ............. ok t/11_io_perl.t ............. ok t/12_io_ioaio.t ............ skipped: AnyEvent::IO::IOAIO not loadable t/61_fltk_01_basic.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_02_signals.t ..... skipped: Broken perl detected\, skipping tests. t/61_fltk_03_child.t ....... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/61_fltk_04_condvar.t ..... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_05_dns.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_07_io.t .......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_09_multi.t ....... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/62_cocoa_01_basic.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_02_signals.t .... skipped: Broken perl detected\, skipping tests. t/62_cocoa_03_child.t ...... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/62_cocoa_04_condvar.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_05_dns.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_07_io.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_09_multi.t ...... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/64_glib_01_basic.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_02_signals.t ..... skipped: Broken perl detected\, skipping tests. t/64_glib_03_child.t ....... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/64_glib_04_condvar.t ..... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_05_dns.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_07_io.t .......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_09_multi.t ....... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/65_event_01_basic.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_02_signals.t .... skipped: Broken perl detected\, skipping tests. t/65_event_03_child.t ...... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/65_event_04_condvar.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_05_dns.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_07_io.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_09_multi.t ...... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/66_ioasync_01_basic.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_02_signals.t .. skipped: Broken perl detected\, skipping tests. t/66_ioasync_03_child.t .... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/66_ioasync_04_condvar.t .. skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_05_dns.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_07_io.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_09_multi.t .... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/67_tk_01_basic.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_02_signals.t ....... skipped: Broken perl detected\, skipping tests. t/67_tk_03_child.t ......... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/67_tk_04_condvar.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_05_dns.t ........... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_07_io.t ............ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_09_multi.t ......... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/68_poe_01_basic.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_02_signals.t ...... skipped: Broken perl detected\, skipping tests. t/68_poe_03_child.t ........ skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/68_poe_04_condvar.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_05_dns.t .......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_07_io.t ........... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_09_multi.t ........ skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/69_ev_01_basic.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_02_signals.t ....... skipped: Broken perl detected\, skipping tests. t/69_ev_03_child.t ......... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/69_ev_04_condvar.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_05_dns.t ........... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_07_io.t ............ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_09_multi.t ......... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/80_ssltest.t ............. skipped: no usable Net::SSLeay t/81_hosts.t ............... ok t/handle/01_readline.t ..... ok t/handle/02_write.t ........ ok t/handle/03_http_req.t ..... skipped: PERL_ANYEVENT_NET_TESTS environment variab le not set t/handle/04_listen.t ....... ok All tests successful. Files=75\, Tests=180\, 4 wallclock secs ( 0.19 usr + 0.09 sys = 0.28 CPU) Result: PASS

C:\Users\Corion\.cpan\build\AnyEvent-7.07-9P6WmP>perl -Ilib -w t\handle\01_readl ine.t 1..8 ok 1 - A line was read correctly ok 2 ok 3 - initial lines were read correctly ok 4 ok 5 ok 6 ok 7 ok 8 - second set of lines were read correctly

p5pRT commented 10 years ago

From @bulk88

no reproduce

Fetching with LWP: http://mirror.cogentco.com/pub/CPAN/authors/id/M/ML/MLEHMANN/CHECKSUMS Checksum for C:\Documents and Settings\Owner\.cpan\sources\authors\id\M\ML\MLEHM ANN\AnyEvent-7.07.tar.gz ok Scanning cache C:\Documents and Settings\Owner\.cpan\build for sizes ............................................................................DONE

Configuring M/ML/MLEHMANN/AnyEvent-7.07.tar.gz with Makefile.PL

Checking if your kit is complete... Looks good Generating a nmake-style Makefile Writing Makefile for AnyEvent Writing MYMETA.yml and MYMETA.json MLEHMANN/AnyEvent-7.07.tar.gz C:\perl519\bin\perl.exe Makefile.PL -- OK Running make for M/ML/MLEHMANN/AnyEvent-7.07.tar.gz

cp lib/AnyEvent/Impl/Event.pm blib\lib/AnyEvent/Impl/Event.pm cp lib/AnyEvent/Impl/EV.pm blib\lib/AnyEvent/Impl/EV.pm cp lib/AnyEvent/Impl/EventLib.pm blib\lib/AnyEvent/Impl/EventLib.pm cp lib/AnyEvent/Impl/IOAsync.pm blib\lib/AnyEvent/Impl/IOAsync.pm cp lib/AnyEvent/Impl/Tk.pm blib\lib/AnyEvent/Impl/Tk.pm cp lib/AnyEvent/Impl/Perl.pm blib\lib/AnyEvent/Impl/Perl.pm cp lib/AnyEvent.pm blib\lib/AnyEvent.pm cp lib/AE.pm blib\lib/AE.pm cp lib/AnyEvent/Impl/Qt.pm blib\lib/AnyEvent/Impl/Qt.pm cp lib/AnyEvent/Impl/Irssi.pm blib\lib/AnyEvent/Impl/Irssi.pm cp lib/AnyEvent/IO.pm blib\lib/AnyEvent/IO.pm cp lib/AnyEvent/IO/Perl.pm blib\lib/AnyEvent/IO/Perl.pm cp lib/AnyEvent/Impl/Glib.pm blib\lib/AnyEvent/Impl/Glib.pm cp lib/AnyEvent/Impl/POE.pm blib\lib/AnyEvent/Impl/POE.pm cp lib/AnyEvent/Handle.pm blib\lib/AnyEvent/Handle.pm cp lib/AnyEvent/Impl/Cocoa.pm blib\lib/AnyEvent/Impl/Cocoa.pm cp lib/AnyEvent/Debug.pm blib\lib/AnyEvent/Debug.pm cp lib/AnyEvent/DNS.pm blib\lib/AnyEvent/DNS.pm cp lib/AnyEvent/FAQ.pod blib\lib/AnyEvent/FAQ.pod cp lib/AnyEvent/IO/IOAIO.pm blib\lib/AnyEvent/IO/IOAIO.pm cp lib/AnyEvent/Impl/FLTK.pm blib\lib/AnyEvent/Impl/FLTK.pm cp lib/AnyEvent/Intro.pod blib\lib/AnyEvent/Intro.pod cp lib/AnyEvent/Util.pm blib\lib/AnyEvent/Util.pm cp lib/AnyEvent/constants.pl blib\arch/AnyEvent/constants.pl cp lib/AnyEvent/Socket.pm blib\lib/AnyEvent/Socket.pm cp lib/AnyEvent/Loop.pm blib\lib/AnyEvent/Loop.pm cp lib/AnyEvent/Util/idna.pl blib\lib/AnyEvent/Util/idna.pl cp lib/AnyEvent/Util/uts46data.pl blib\lib/AnyEvent/Util/uts46data.pl cp lib/AnyEvent/TLS.pm blib\lib/AnyEvent/TLS.pm cp lib/AnyEvent/Log.pm blib\lib/AnyEvent/Log.pm cp lib/AnyEvent/Strict.pm blib\lib/AnyEvent/Strict.pm C:\perl519\bin\perl.exe "-Iblib\arch" "-Iblib\lib" constants.pl.PL const ants.pl MLEHMANN/AnyEvent-7.07.tar.gz "C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN\nmake.EXE" -- OK Running make test

Skip blib\lib/AnyEvent/IO/Perl.pm (unchanged) Skip blib\lib/AnyEvent/Impl/IOAsync.pm (unchanged) Skip blib\lib/AnyEvent/Impl/EV.pm (unchanged) Skip blib\lib/AnyEvent/Impl/Qt.pm (unchanged) Skip blib\lib/AnyEvent/IO/IOAIO.pm (unchanged) Skip blib\lib/AnyEvent/Impl/Glib.pm (unchanged) Skip blib\lib/AnyEvent/Handle.pm (unchanged) Skip blib\lib/AnyEvent/Impl/POE.pm (unchanged) Skip blib\lib/AnyEvent/IO.pm (unchanged) Skip blib\lib/AnyEvent/Intro.pod (unchanged) Skip blib\lib/AnyEvent/Impl/Tk.pm (unchanged) Skip blib\lib/AnyEvent/Impl/Cocoa.pm (unchanged) Skip blib\lib/AnyEvent/Impl/Event.pm (unchanged) Skip blib\lib/AnyEvent.pm (unchanged) Skip blib\lib/AnyEvent/Impl/Perl.pm (unchanged) Skip blib\lib/AnyEvent/Debug.pm (unchanged) Skip blib\lib/AnyEvent/FAQ.pod (unchanged) Skip blib\lib/AnyEvent/Impl/EventLib.pm (unchanged) Skip blib\lib/AnyEvent/Impl/Irssi.pm (unchanged) Skip blib\lib/AnyEvent/Impl/FLTK.pm (unchanged) Skip blib\lib/AE.pm (unchanged) Skip blib\lib/AnyEvent/DNS.pm (unchanged) Skip blib\lib/AnyEvent/Loop.pm (unchanged) Skip blib\lib/AnyEvent/Util.pm (unchanged) Skip blib\lib/AnyEvent/Strict.pm (unchanged) Skip blib\lib/AnyEvent/Util/uts46data.pl (unchanged) Skip blib\lib/AnyEvent/Log.pm (unchanged) cp lib/AnyEvent/constants.pl blib\arch/AnyEvent/constants.pl Skip blib\lib/AnyEvent/TLS.pm (unchanged) Skip blib\lib/AnyEvent/Socket.pm (unchanged) Skip blib\lib/AnyEvent/Util/idna.pl (unchanged) C:\perl519\bin\perl.exe "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0\, 'blib\lib'\, 'blib\arch')" t/*. t t/handle/*.t t/00_load.t ................ ok t/01_basic.t ............... ok t/02_signals.t ............. skipped: Broken perl detected\, skipping tests. t/03_child.t ............... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/04_condvar.t ............. ok t/05_dns.t ................. ok t/06_socket.t .............. ok t/07_io.t .................. ok t/08_idna.t ................ ok t/09_multi.t ............... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/10_loadall.t ............. ok t/11_io_perl.t ............. ok t/12_io_ioaio.t ............ skipped: AnyEvent::IO::IOAIO not loadable t/61_fltk_01_basic.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_02_signals.t ..... skipped: Broken perl detected\, skipping tests. t/61_fltk_03_child.t ....... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/61_fltk_04_condvar.t ..... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_05_dns.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_07_io.t .......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/61_fltk_09_multi.t ....... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/62_cocoa_01_basic.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_02_signals.t .... skipped: Broken perl detected\, skipping tests. t/62_cocoa_03_child.t ...... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/62_cocoa_04_condvar.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_05_dns.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_07_io.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/62_cocoa_09_multi.t ...... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/64_glib_01_basic.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_02_signals.t ..... skipped: Broken perl detected\, skipping tests. t/64_glib_03_child.t ....... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/64_glib_04_condvar.t ..... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_05_dns.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_07_io.t .......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/64_glib_09_multi.t ....... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/65_event_01_basic.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_02_signals.t .... skipped: Broken perl detected\, skipping tests. t/65_event_03_child.t ...... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/65_event_04_condvar.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_05_dns.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_07_io.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/65_event_09_multi.t ...... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/66_ioasync_01_basic.t .... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_02_signals.t .. skipped: Broken perl detected\, skipping tests. t/66_ioasync_03_child.t .... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/66_ioasync_04_condvar.t .. skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_05_dns.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_07_io.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/66_ioasync_09_multi.t .... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/67_tk_01_basic.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_02_signals.t ....... skipped: Broken perl detected\, skipping tests. t/67_tk_03_child.t ......... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/67_tk_04_condvar.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_05_dns.t ........... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_07_io.t ............ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/67_tk_09_multi.t ......... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/68_poe_01_basic.t ........ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_02_signals.t ...... skipped: Broken perl detected\, skipping tests. t/68_poe_03_child.t ........ skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/68_poe_04_condvar.t ...... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_05_dns.t .......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_07_io.t ........... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/68_poe_09_multi.t ........ skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/69_ev_01_basic.t ......... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_02_signals.t ....... skipped: Broken perl detected\, skipping tests. t/69_ev_03_child.t ......... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/69_ev_04_condvar.t ....... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_05_dns.t ........... skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_07_io.t ............ skipped: PERL_ANYEVENT_LOOP_TESTS not true t/69_ev_09_multi.t ......... skipped: Your perl interpreter is badly BROKEN. Chi ld watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK . t/80_ssltest.t ............. skipped: no usable Net::SSLeay t/81_hosts.t ............... ok t/handle/01_readline.t ..... ok t/handle/02_write.t ........ ok t/handle/03_http_req.t ..... skipped: PERL_ANYEVENT_NET_TESTS environment variab le not set t/handle/04_listen.t ....... ok All tests successful. Files=75\, Tests=180\, 7 wallclock secs ( 0.30 usr + 0.08 sys = 0.38 CPU) Result: PASS MLEHMANN/AnyEvent-7.07.tar.gz "C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN\nmake.EXE" test -- OK

cpan[2]> q Terminal does not support GetHistory. Lockfile removed.

C:\>perl -v

This is perl 5\, version 19\, subversion 12 (v5.19.12 (v5.19.11-19-g6057286*)) bui lt for MSWin32-x86-multi-thread (with 2 registered patches\, see perl -V for more detail)

Perl may be copied only under the terms of either the Artistic License or the GNU General Public License\, which may be found in the Perl 5 source kit.

C:\>

self compiled VC 2003 perl on WinXP 32 bits

-- bulk88 ~ bulk88 at hotmail.com

p5pRT commented 10 years ago

From @rjbs

Closed as this is likely the issue in https://rt-archive.perl.org/perl5/Ticket/Display.html?id=119433#txn-1291542

-- rjbs

p5pRT commented 10 years ago

@rjbs - Status changed from 'open' to 'resolved'

p5pRT commented 10 years ago

From @rjbs

(Please\, by all means\, if you can provide steps to reproduce this which can demonstrate that it is a distinct bug\, let us know. I am not trying to dismiss an unknown problem\, but to suggest that the transaction linked-to above would explain a strange failure that can't be reproduced by other testers immediately.)

-- rjbs

p5pRT commented 9 years ago

From m.nooning@comcast.net

Please reopen this ticket. This is repeatable for me on Windows XP. I was seeing it in Strawberry v5.20 so I upgraded to v5.20.1\, and I get the same thing. I use "cpan install AnyEvent" in a prompt box to see it.

p5pRT commented 9 years ago

From m.nooning@comcast.net

Hmmm. I see this is judged to be the same bug as 1291542\, so I will report this in that ticket instead. Thanks

p5pRT commented 9 years ago

From @ikegami

On Tue\, Apr 29\, 2014 at 10:13 AM\, Steve Hay via RT \< perlbug-followup@perl.org> wrote:

The gcc build test results are attached. Loads of tests shout that my perl is BROKEN (?!)\, but the test in question passes.

Looks like the test are being run in cygwin\, not Windows?

p5pRT commented 9 years ago

From m.nooning@comcast.net

The tests are in a Windows command prompt. I will show the first two "not okay" lines. After this there are many such lines. I will then paste the short test summary. t/00_load.t ................ ok t/01_basic.t ............... ok t/02_signals.t ............. skipped: Broken perl detected\, skipping tests. t/03_child.t ............... skipped: Your perl interpreter is badly BROKEN. Child watchers will not work\, ever. Try upgrading to a newer perl or a working perl (cygwin's perl is known to work). If that is not an option\, you should be able to use the remaining functionality of AnyEvent\, but child watchers WILL NOT WORK. t/04_condvar.t ............. ok

Test Summary Report

t/handle/01_readline.t (Wstat: 35840 Tests: 3 Failed: 0) Non-zero exit status: 140 Parse errors: Bad plan. You planned 8 tests but ran 3. Files=75\, Tests=590\, 11 wallclock secs ( 0.45 usr + 0.14 sys = 0.59 CPU) Result: FAIL Failed 1/75 test programs. 0/590 subtests failed. dmake.exe: Error code 255\, while making 'test_dynamic' MLEHMANN/AnyEvent-7.07.tar.gz C:\Perl\c\bin\dmake.exe test -- NOT OK //hint// to see the cpan-testers results for installing this module\, try: reports MLEHMANN/AnyEvent-7.07.tar.gz Stopping: 'install' failed for 'AnyEvent'.

C:\Documents and Settings\Malcolm\My Documents\Downloads>perl -v

This is perl 5\, version 20\, subversion 1 (v5.20.1) built for MSWin32-x86-multi-thread-64int

Just for the exercise\, I tried it on my cygwin\, same machine. Cygwin has Perl v5.14.2. The cygwin attempt at "cpan install AnyEvent" looks stuck in an endless loop printing out lines like that below (slightly edited by me): "single digit 1 or 2" [main] perl "four digits" child_info_fork::abort: unable to remap SHA.dll to same address as parent ("hex address") - try running rebaseall

Thanks

p5pRT commented 9 years ago

From m.nooning@comcast.net

By the way\, my Windows prompt perl says 64 bit\, even though I installed it from the supposed 32 bit msi: strawberry-perl-5.20.1.1-32bit.msi

Could there be a mixup on the creation of perl-5.20.1.1-32bit.msi?

p5pRT commented 9 years ago

From @ikegami

On Thu\, Sep 25\, 2014 at 2:29 PM\, Malcolm Nooning via RT \< perlbug-followup@perl.org> wrote:

By the way\, my Windows prompt perl says 64 bit\, even though I installed it from the supposed 32 bit msi: strawberry-perl-5.20.1.1-32bit.msi

Could there be a mixup on the creation of perl-5.20.1.1-32bit.msi?

"MSWin32-x86-multi-thread-64int" means it's a 32-bit program (x86 instead of x86_64) using 64-bit ints.

p5pRT commented 9 years ago

From laurent.aml@gmail.com

I got this issue with Strawberry Perl 5.20.2.1 (32bits\, int64)\, on Windows 7 64bits.

C:\0\strawberry-perl-5.20.2.1-32bit\cpan\build\AnyEvent-7.08-zCulrH>..\..\..\perl\bin\perl.exe -Ilib t\handle\01_readline.t 1..8 ok 1 - A line was read correctly ok 2 ok 3 - initial lines were read correctly AnyEvent::Handle uncaught error: A non-blocking socket operation could not be completed immediately. at t\handle\01_readline.t line 77. # Looks like you planned 8 tests but ran 3. # Looks like your test exited with 140 just after 3.

AnyEvent::Handle expects syswrite to return EAGAIN(11)\, EINTR(4) or AnyEvent::Util::WSAEWOULDBLOCK(10035) errors when buffers are full\, but syswrite returns POSIX::EWOULDBLOCK(140) instead in this case.

Catching POSIX::EWOULDBLOCK in AnyEvent::Handle fixes the issue. Perl 5.12 delta claims that "socket error codes are now more widely supported". I guess the EWSAWOULDBLOCK anomaly has been fixed and EWOULDBLOCK can now be used instead?

p5pRT commented 9 years ago

From [Unknown Contact. See original ticket]

I got this issue with Strawberry Perl 5.20.2.1 (32bits\, int64)\, on Windows 7 64bits.

p5pRT commented 9 years ago

From @steve-m-hay

On 11 March 2015 at 19:46\, Laurent Aml via RT \perlbug\-comment@perl\.org wrote:

I got this issue with Strawberry Perl 5.20.2.1 (32bits\, int64)\, on Windows 7 64bits.

C:\0\strawberry-perl-5.20.2.1-32bit\cpan\build\AnyEvent-7.08-zCulrH>..\..\..\perl\bin\perl.exe -Ilib t\handle\01_readline.t 1..8 ok 1 - A line was read correctly ok 2 ok 3 - initial lines were read correctly AnyEvent::Handle uncaught error: A non-blocking socket operation could not be completed immediately. at t\handle\01_readline.t line 77. # Looks like you planned 8 tests but ran 3. # Looks like your test exited with 140 just after 3.

AnyEvent::Handle expects syswrite to return EAGAIN(11)\, EINTR(4) or AnyEvent::Util::WSAEWOULDBLOCK(10035) errors when buffers are full\, but syswrite returns POSIX::EWOULDBLOCK(140) instead in this case.

Catching POSIX::EWOULDBLOCK in AnyEvent::Handle fixes the issue. Perl 5.12 delta claims that "socket error codes are now more widely supported". I guess the EWSAWOULDBLOCK anomaly has been fixed and EWOULDBLOCK can now be used instead?

Yes\, EWOULDBLOCK should be used instead of AnyEvent::Util::WSAEWOULDBLOCK\, which was basically a hard-wired 10035. Really\, EWOULDBLOCK should have been used all along\, and then no breakage would have occurred.

The change in EWOULDBLOCK value was caused by a series of commits dealing with the handling of new Exxx constants in errno.h in VC++ 2010 onwards\, which recent versions of gcc (which Strawberry Perl is built with) have picked up. The commits in question are b0ba219002 through 7bf1409065\, merged into blead by commit ea95436966. In particular\, see:

http://perl5.git.perl.org/perl.git/commit/c9beaf974d

The effect of that commit is that (with VC++ 2010+ and recent gcc builds) prior to 5.19.4\, if WSAEWOULDBLOCK (10035) was assigned to $! then the value of 0+$! would simply be 10035\, but now the value will be 140 because WSAEWOULDBLOCK is mapped to the corresponding Exxx constant (namely\, EWOULDBLOCK\, which has the value 140):

C:\Dev\Temp\perl-5.19.3>.\perl -le "$! = 10035; print 0+$!" 10035

C:\Dev\Temp\perl-5.20.2>.\perl -le "$! = 10035; print 0+$!" 140

As the commits noted\, this level of breakage in modules testing directly for 10035 instead of EWOULDBLOCK was unavoidable.

p5pRT commented 9 years ago

From laurent.aml@gmail.com

This ticket should be reopened; current Perl is broken regarding the handling of WSA* winsock errors. WSA* error names are not Posix. While some error codes with similar names may have similar meanings\, several of them have completely different ones. WSAEINPROGRESS for example\, when returned from connect() implies that the connect failed\, while for Posix\, EINPROGRESS means the connect is ongoing. So using Posix codes in place of WSA* one looks like a recipe for disaster\, and one should not expect others to consider this a good practice.

Secondly\, the change of the EWOULBLOCK value to 140 is a Perl decision\, not dictated by VC 2010. Windows still uses 10035 for WSAEWOULDBLOCK (and returns that from winsock). VC 2010 certainly defines EWOULDBLOCK as 140\, but I don't see how this particular EWOULDBLOCK is of any use in Perl? Though\, doing this has intentionally introduced backward compatibility issues\, to prevent some hypothetical future breakage. At least\, I think Perl should revert back to using WSA* values as in previous Perl versions\, to fix the current issue. While not fixing the mix of WSA*/Posix codes with incompatible meanings\, it would prevent some backward compatibility issues\, without much (if any?) drawback.

It is also worth noting that AnyEvent has been subtly broken for years on non-cygwin Windows Perl because EINPROGRESS has been mapped to WSAEINPROGRESS.

Finally\, Marc Lehmann is much more knowledgeable than me on the subject. The above technical findings are his. Please refer to the perl5-porters or AnyEvent mailing lists for more details.

p5pRT commented 9 years ago

From [Unknown Contact. See original ticket]

It is also worth noting that AnyEvent has been subtly broken for years on non-cygwin Windows Perl because EINPROGRESS has been mapped to WSAEINPROGRESS.

Finally\, Marc Lehmann is much more knowledgeable than me on the subject. The above technical findings are his. Please refer to the perl5-porters or AnyEvent mailing lists for more details.

p5pRT commented 9 years ago

From @steve-m-hay

On 18 March 2015 at 23:44\, Laurent Aml via RT \perlbug\-comment@perl\.org wrote:

This ticket should be reopened; current Perl is broken regarding the handling of WSA* winsock errors. WSA* error names are not Posix. While some error codes with similar names may have similar meanings\, several of them have completely different ones. WSAEINPROGRESS for example\, when returned from connect() implies that the connect failed\, while for Posix\, EINPROGRESS means the connect is ongoing. So using Posix codes in place of WSA* one looks like a recipe for disaster\, and one should not expect others to consider this a good practice.

Secondly\, the change of the EWOULBLOCK value to 140 is a Perl decision\, not dictated by VC 2010. Windows still uses 10035 for WSAEWOULDBLOCK (and returns that from winsock). VC 2010 certainly defines EWOULDBLOCK as 140\, but I don't see how this particular EWOULDBLOCK is of any use in Perl? Though\, doing this has intentionally introduced backward compatibility issues\, to prevent some hypothetical future breakage. At least\, I think Perl should revert back to using WSA* values as in previous Perl versions\, to fix the current issue. While not fixing the mix of WSA*/Posix codes with incompatible meanings\, it would prevent some backward compatibility issues\, without much (if any?) drawback.

It is also worth noting that AnyEvent has been subtly broken for years on non-cygwin Windows Perl because EINPROGRESS has been mapped to WSAEINPROGRESS.

Finally\, Marc Lehmann is much more knowledgeable than me on the subject. The above technical findings are his. Please refer to the perl5-porters or AnyEvent mailing lists for more details.

The non-equivalence of like-named Winsock/POSIX error codes appears not to be widely known. Several commits over the years (first in Errno.pm in 5.8\, then in POSIX.pm in 5.12\, and more recently in some win32/ functions in 5.20) have not shown any awareness of this\, and from Googling around it is clear that numerous other scripting languages (PHP\, Python\, Ruby and Tcl) and other open source projects appear to set up similar equivalences.

It was on this basis that it was assumed that anyone wishing to test whether a Winsock error was WSAEWOULDBLOCK would use the EWOULDBLOCK constant exported by by Errno.pm and POSIX.pm\, the value of which was set to WSAEWOULDBLOCK's value. Such a test for $!==EWOULDBLOCK works exactly as it did before because not only has EWOULDBLOCK's value been changed from 10035 to 140 but the value put in $! has also been changed from 10035 to 140 in such a case. Thus\, anyone using this named constant would not even notice that things have changed "under the hood".

The reason that EWOULDBLOCK's value has changed from 10035 to 140 is\, of course\, to reflect the change in errno.h in VC10 and above (and now in recent gccs too). Previously they didn't define EWOULDBLOCK\, and many Exxx constants for which errno.h provided no value have long been given the value of the like-named WSAExxx constant; now\, in VC10 and above\, errno.h defines EWOULDBLOCK as 140.

It is true that we could always set EWOULDBLOCK to the WSAEWOULDBLOCK value\, even when errno.h gives us a value already\, but this raises the question of what is expected of the constants exported by Errno.pm/POSIX.pm: Should they generally reflect the errno.h values of the compiler used as far as possible (and only use Winsock values for those that are still not in errno.h)\, or should they generally be set to like-named Winsock values wherever possible (and only retain their errno.h values where there is no like-named Winsock value)? (We would end up with a mix of both either way\, of course.)

My worry about the latter approach (which is what you've suggested as a minimal partial solution to these issues) was that the Exxx constants are not only used in socket programming. If other (non-socket-related) CRT functions on Windows make use of some of the new errno.h constants (e.g. if some CRT function like fread() or system() happens to fail and set errno to one of the new Exxx values) then the corresponding check in a Perl program (comparing $! to the relevant Exxx constant) would then fail because the Exxx constant exposed by Perl will have been changed to a Winsock-related value.

That is why I took the former approach instead\, which is a safe change except for the case where users test $! against hard-coded numbers like 10035 instead the Exxx constants.

Finally\, on the subject of EINPROGRES vs WSAEINPROGRESS I would also note that EINPROGRESS applies to non-blocking connections\, while WSAEINPROGRESS applies to blocking connections. So not only do they have opposite meaning (success vs failure)\, they are also used in different contexts. Does this fact help to find a workaround with current perls? I.e. If you handle blocking and non-blocking connections separately then are you able to unambiguously test for one condition or the other without getting an accidental "false postiive"? I have no deep knowledge in this area\, it's just a thought that struck me as something that might be worth exploring.

The only really robust solution that I have in mind right now for how to solve all of this is to have a Perl module that explicitly exports the WSAExxx values in their own set of WSAExxx constants\, and change Errno.pm/POSIX.pm to only export the Exxx constants that are defined in errno.h. That\, of course\, would also cause a lot of upheaval for people\, having to adapt their code to use the new constants\, but would at least solve the problem once for all for the future.

We have somebody looking into all of this right now\, and hope to come up with a solution in due course.

I am reopening this ticket in the meantime until these issues are resolved.

p5pRT commented 9 years ago

@steve-m-hay - Status changed from 'resolved' to 'open'

p5pRT commented 9 years ago

From laurent.aml@gmail.com

Morning\,

On Thu\, Mar 19\, 2015 at 5:47 AM\, Steve Hay \steve\.m\.hay@googlemail\.com wrote:

On 18 March 2015 at 23:44\, Laurent Aml via RT \perlbug\-comment@perl\.org wrote:

This ticket should be reopened; current Perl is broken regarding the handling of WSA* winsock errors. WSA* error names are not Posix. While some error codes with similar names may have similar meanings\, several of them have completely different ones. WSAEINPROGRESS for example\, when returned from connect() implies that the connect failed\, while for Posix\, EINPROGRESS means the connect is ongoing. So using Posix codes in place of WSA* one looks like a recipe for disaster\, and one should not expect others to consider this a good practice.

Secondly\, the change of the EWOULBLOCK value to 140 is a Perl decision\, not dictated by VC 2010. Windows still uses 10035 for WSAEWOULDBLOCK (and returns that from winsock). VC 2010 certainly defines EWOULDBLOCK as 140\, but I don't see how this particular EWOULDBLOCK is of any use in Perl? Though\, doing this has intentionally introduced backward compatibility issues\, to prevent some hypothetical future breakage. At least\, I think Perl should revert back to using WSA* values as in previous Perl versions\, to fix the current issue. While not fixing the mix of WSA*/Posix codes with incompatible meanings\, it would prevent some backward compatibility issues\, without much (if any?) drawback.

It is also worth noting that AnyEvent has been subtly broken for years on non-cygwin Windows Perl because EINPROGRESS has been mapped to WSAEINPROGRESS.

Finally\, Marc Lehmann is much more knowledgeable than me on the subject. The above technical findings are his. Please refer to the perl5-porters or AnyEvent mailing lists for more details.

The non-equivalence of like-named Winsock/POSIX error codes appears not to be widely known. Several commits over the years (first in Errno.pm in 5.8\, then in POSIX.pm in 5.12\, and more recently in some win32/ functions in 5.20) have not shown any awareness of this\, and from Googling around it is clear that numerous other scripting languages (PHP\, Python\, Ruby and Tcl) and other open source projects appear to set up similar equivalences.

It was on this basis that it was assumed that anyone wishing to test whether a Winsock error was WSAEWOULDBLOCK would use the EWOULDBLOCK

Now that we know that the basis is false\, what has been deducted from it is no more relevant.

[...]

The reason that EWOULDBLOCK's value has changed from 10035 to 140 is\, of course\, to reflect the change in errno.h in VC10 and above (and now in recent gccs too). Previously they didn't define EWOULDBLOCK\, and many Exxx constants for which errno.h provided no value have long been given the value of the like-named WSAExxx constant; now\, in VC10 and above\, errno.h defines EWOULDBLOCK as 140.

This sounds like a lemming argument to me: MS decides to do something\, Perl follows without giving a second thought. And note that neither VC10 nor gcc have redefined the winsock error codes as you did (how could they\, anyway).

It is true that we could always set EWOULDBLOCK to the WSAEWOULDBLOCK

And this is what Perl had been doing happily for years.

value\, even when errno.h gives us a value already\, but this raises the

question of what is expected of the constants exported by Errno.pm/POSIX.pm: Should they generally reflect the errno.h values of the compiler used as far as possible (and only use Winsock values for those that are still not in errno.h)\, or should they generally be set to like-named Winsock values wherever possible (and only retain their errno.h values where there is no like-named Winsock value)? (We would end up with a mix of both either way\, of course.)

The real issue is somewhere else actually. It does not really matter what values you choose for Perl Posix codes. The problem is that Winsock is now returning pseudo Posix codes\, instead of the WSA* one.

Now\, you don't mind breaking the backward compatibility for AnyEvent/IO::Socket as it did the thing right (not mixing WSA and Posix codes)\, but it appears you have a concern about breaking the compatibility for those that would use the Posix codes to test winsock errors: that's the only reason I figured out why you would have changed the winsock error codes at the same time you changed the Posix one. That's not fair. Especially as the solution is obvious: using WSA values for Perl Posix codes keeps the backward compatibility for both.

My worry about the latter approach (which is what you've suggested as a minimal partial solution to these issues) was that the Exxx constants are not only used in socket programming. If other (non-socket-related) CRT functions on Windows make use of some of the new errno.h constants (e.g. if some CRT function like fread() or system() happens to fail and set errno to one of the new Exxx values) then the corresponding check in a Perl program (comparing $! to the relevant Exxx constant) would then fail because the Exxx constant exposed by Perl will have been changed to a Winsock-related value.

This is what I call breaking things now in an attempt to prevent hypothetical future breakage.

Also\, converting CRT error codes to any Perl's code (such as WSA* ones) would address your concern as well\, without breaking the backward compatibility.

But worse\, the Perl Posix error codes currently have the winsock semantics ($! = EINPROGRESS\, print $!; => "A blocking operation is currently executing." instead of "Operation now in progress"). So the future breakage that you tried to avoid already happens\, as the Posix error message is wrong. Maybe I am assuming too much that Windows Posix codes have Posix meaning. Maybe I see the glass half empty: on the other side\, you fixed the error message for those using EINPROGRESS with winsock on Windows.

That is why I took the former approach instead\, which is a safe change except for the case where users test $! against hard-coded numbers like 10035 instead the Exxx constants.

Arguments have been given why using the Exxx constants to test winsock errors is potentially wrong. And Perl core does not provide constants for winsock\, leaving modules to use hard coded values. Knowing this\, I do not consider the change safe.

Finally\, on the subject of EINPROGRES vs WSAEINPROGRESS I would also note that EINPROGRESS applies to non-blocking connections\, while WSAEINPROGRESS applies to blocking connections. So not only do they

have opposite meaning (success vs failure)\, they are also used in different contexts. Does this fact help to find a workaround with current perls? I.e. If you handle blocking and non-blocking connections separately then are you able to unambiguously test for one condition or the other without getting an accidental "false postiive"? I have no deep knowledge in this area\, it's just a thought that struck me as something that might be worth exploring.

Neither do I have deep knowledge on this. Though\, affecting 2 different semantics to the same code depending on the OS is really bad. If ever Windows starts to use Posix code for their Posix meaning\, you will be in a bad situation\, as currently you are attaching the Winsock sementics to those codes.

The only really robust solution that I have in mind right now for how to solve all of this is to have a Perl module that explicitly exports

Using WSA* code as in previous Perl versions is not as robust\, but at least is more robust than the current solution.

the WSAExxx values in their own set of WSAExxx constants\, and change

That part is easy and does not break anything\, but the constants would be useless as long as the winsock calls are not setting those values.

Errno.pm/POSIX.pm to only export the Exxx constants that are defined in errno.h. That\, of course\, would also cause a lot of upheaval for people\, having to adapt their code to use the new constants\, but would at least solve the problem once for all for the future.

That's the tricky part. Though\, it has been suggested that case could be made to merge WSA and Exxx codes when their semantics are matching and not incompatible (for concerned system calls). And you can decide what your Posix error codes are in Perl. They do not have to match exactly those of Windows. As said before\, if you find acceptable to translate WSA codes to Windows' Exxx ones\, I don't see why you could not conversely translate Windows' Exxx ones to WSA* if it works better. Obviously\, doing things like keeping Perl's EWOULDBLOCK equal to WSAEWOULDBLOCK (more importantly: letting winsock calls return winsock errors) would restore the backward compatibility as it was before the change.

Regards\,

-- Laurent

p5pRT commented 9 years ago

From @ap

* Steve Hay \steve\.m\.hay@googlemail\.com [2015-03-19 10:50]:

Finally\, on the subject of EINPROGRES vs WSAEINPROGRESS I would also note that EINPROGRESS applies to non-blocking connections\, while WSAEINPROGRESS applies to blocking connections. So not only do they have opposite meaning (success vs failure)\, they are also used in different contexts. Does this fact help to find a workaround with current perls? I.e. If you handle blocking and non-blocking connections separately then are you able to unambiguously test for one condition or the other without getting an accidental "false postiive"? I have no deep knowledge in this area\, it's just a thought that struck me as something that might be worth exploring.

Even if it helps\, consider how you would have to write code that makes use of this knowledge to distinguish the cases. It’s certainly not the type of thing I would wish to have to shake the bugs out of and then maintain on an ongoing basis.

The only really robust solution that I have in mind right now for how to solve all of this is to have a Perl module that explicitly exports the WSAExxx values in their own set of WSAExxx constants\, and change Errno.pm/POSIX.pm to only export the Exxx constants that are defined in errno.h. That\, of course\, would also cause a lot of upheaval for people\, having to adapt their code to use the new constants\, but would at least solve the problem once for all for the future.

From the outside\, this seems the only real answer.

Consider in particular what this means for feature detect switches in libraries like AnyEvent which try to take care of all the details no matter the platform and perl you are running them on. The test becomes very simple and reliable: you just try to import the WSAE constants\, and if that succeeds then you know you can use sane semantics.

Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 9 years ago

From @steve-m-hay

On 19 March 2015 at 18:11\, Laurent \laurent\.aml@gmail\.com wrote:

Morning\,

Evening ;-)

On Thu\, Mar 19\, 2015 at 5:47 AM\, Steve Hay \steve\.m\.hay@googlemail\.com wrote:

On 18 March 2015 at 23:44\, Laurent Aml via RT \perlbug\-comment@perl\.org wrote:

This ticket should be reopened; current Perl is broken regarding the handling of WSA* winsock errors. WSA* error names are not Posix. While some error codes with similar names may have similar meanings\, several of them have completely different ones. WSAEINPROGRESS for example\, when returned from connect() implies that the connect failed\, while for Posix\, EINPROGRESS means the connect is ongoing. So using Posix codes in place of WSA* one looks like a recipe for disaster\, and one should not expect others to consider this a good practice.

Secondly\, the change of the EWOULBLOCK value to 140 is a Perl decision\, not dictated by VC 2010. Windows still uses 10035 for WSAEWOULDBLOCK (and returns that from winsock). VC 2010 certainly defines EWOULDBLOCK as 140\, but I don't see how this particular EWOULDBLOCK is of any use in Perl? Though\, doing this has intentionally introduced backward compatibility issues\, to prevent some hypothetical future breakage. At least\, I think Perl should revert back to using WSA* values as in previous Perl versions\, to fix the current issue. While not fixing the mix of WSA*/Posix codes with incompatible meanings\, it would prevent some backward compatibility issues\, without much (if any?) drawback.

It is also worth noting that AnyEvent has been subtly broken for years on non-cygwin Windows Perl because EINPROGRESS has been mapped to WSAEINPROGRESS.

Finally\, Marc Lehmann is much more knowledgeable than me on the subject. The above technical findings are his. Please refer to the perl5-porters or AnyEvent mailing lists for more details.

The non-equivalence of like-named Winsock/POSIX error codes appears not to be widely known. Several commits over the years (first in Errno.pm in 5.8\, then in POSIX.pm in 5.12\, and more recently in some win32/ functions in 5.20) have not shown any awareness of this\, and from Googling around it is clear that numerous other scripting languages (PHP\, Python\, Ruby and Tcl) and other open source projects appear to set up similar equivalences.

It was on this basis that it was assumed that anyone wishing to test whether a Winsock error was WSAEWOULDBLOCK would use the EWOULDBLOCK

Now that we know that the basis is false\, what has been deducted from it is no more relevant.

But it is relevant for explaining the decisions taken: If you look at what was done whilst keeping in mind what we believed to be true then you will see that the actions taken were precisely because we *do* very much have a care for backwards compatibility. It does rather irk me that the idea of us not caring about backwards compatibility keeps being aired. The breakage was caused because the initial understanding was wrong; not because we didn't care.

[...]

The reason that EWOULDBLOCK's value has changed from 10035 to 140 is\, of course\, to reflect the change in errno.h in VC10 and above (and now in recent gccs too). Previously they didn't define EWOULDBLOCK\, and many Exxx constants for which errno.h provided no value have long been given the value of the like-named WSAExxx constant; now\, in VC10 and above\, errno.h defines EWOULDBLOCK as 140.

This sounds like a lemming argument to me: MS decides to do something\, Perl follows without giving a second thought. And note that neither VC10 nor gcc have redefined the winsock error codes as you did (how could they\, anyway).

It is true that we could always set EWOULDBLOCK to the WSAEWOULDBLOCK

And this is what Perl had been doing happily for years.

You've cut off the second half of my sentence there. Perl has not previously been setting EWOULDBLOCK to WSAEWOULDBLOCK *when errno.h gives us a value already*. It's only previously set EWOULDBLOCK to WSAEWOULDBLOCK when no natural value to use was already in the system.

value\, even when errno.h gives us a value already\, but this raises the question of what is expected of the constants exported by Errno.pm/POSIX.pm: Should they generally reflect the errno.h values of the compiler used as far as possible (and only use Winsock values for those that are still not in errno.h)\, or should they generally be set to like-named Winsock values wherever possible (and only retain their errno.h values where there is no like-named Winsock value)? (We would end up with a mix of both either way\, of course.)

The real issue is somewhere else actually. It does not really matter what values you choose for Perl Posix codes. The problem is that Winsock is now returning pseudo Posix codes\, instead of the WSA* one.

Now\, you don't mind breaking the backward compatibility for AnyEvent/IO::Socket as it did the thing right (not mixing WSA and Posix codes)\, but it appears you have a concern about breaking the compatibility for those that would use the Posix codes to test winsock errors: that's the only reason I figured out why you would have changed the winsock error codes at the same time you changed the Posix one.

I take exception with the first part of that paragraph. As I wrote above\, we certainly *do* mind breaking backwards compatibility\, and strove very hard not to do so. We believed that people wishing to check for Winsock error codes such as WSAEWOULDBLOCK would do so on Windows by testing $! against EWOULDBLOCK: Facilitating that was presumably the intent of the original Errno.pm change (http://perl5.git.perl.org/perl.git/commit/4d70086c95) which first exported Errno::EWOULDBLOCK with the value set to WSAEWOULDBLOCK's value\, and since that first appeared in 5.8.0 in 2002 we assumed that the practice would be well established by now.

Indeed\, we seem to have further encouraged people to check for Winsock errors by testing $! against Exxx constants by exporting the same Winsock-valued Exxx constants from POSIX.pm as of 5.12 (http://perl5.git.perl.org/perl.git/commit/2489f03d17) as well. I imagine the thinking behind those changes was (ironically\, it would now appear) that this would make writing portable code easier: One could simply test $! against Exxx constants exported from either Errno.pm or POSIX.pm on all platforms\, instead of having to do that on *nix and muck around with different values on Windows. Obviously that breaks down if the values thus put into various Exxx constants mean different things on *nix and Windows\, but since that wasn't known to us at the time it couldn't have been accounted for.

That's not fair. Especially as the solution is obvious: using WSA values for Perl Posix codes keeps the backward compatibility for both.

If I understand you correctly\, you are suggesting that we should do this:

#ifdef EWOULDBLOCK #undef EWOULDBLOCK #endif #define EWOULDBLOCK WSAEWOULDBLOCK

and keep Winsock error codes in $!.

This is indeed apparently the most obvious solution\, and was actually the first approach that was attempted when trying to fix the VC10 build. It was done in commit http://perl5.git.perl.org/perl.git/commit/b59e75b34c for both Errno.pm and POSIX.pm\, but that lead to conflict within the perl core (the C code) because the values it was using for the Exxx constants affected were then out of sync with the values exported by Errno.pm and POSIX.pm. Thus\, C code putting ECONNABORTED into errno would yield a different value in $! (namely\, 106) compared to Perl code putting ECONNABORTED into $! (namely\, 10053).

Therefore\, a follow-up commit (http://perl5.git.perl.org/perl.git/commit/912c63ed00) additionally redefined those Exxx constants that the perl core used in the same manner as was done above for Errno.pm/POSIX.pm\, but now in the C code of the perl core too (in an installed header file\, for the benefit of XS code that might also assign POSIX error codes to errno; arguably the change should have redefined all the Exxx values that Errno.pm/POSIX.pm redefined\, rather than restricting itself to only those few used in the perl core).

However\, this resulted in compatibility problems with other libraries. Specifically\, breakage was found in mod_perl: Apache httpd obviously uses the standard errno.h value of 106 for ECONNABORTED\, but XS modules picked up perl's redefined errno.h value of 10053\, leading to a failure to recognize some errno values set by httpd.

This is why it was decided to jump the other way instead\, changing the values put into $! and changing the values of the Exxx constants to match\, believing that that's what people would be testing $! against. You can read the full gory details in the merge commit http://perl5.git.perl.org/perl.git/commit/ea95436966 and the 11 commits before it (which constitute what was merged in).

So to me the solution here is not at all obvious:

* We have tried redefining Exxx constants to WSAExxx values\, but that needs doing in C code as well as Perl code\, and the former conflicts when linking against other C libraries that were not built with similarly redefined Exxx constants. [This was the first attempt\, which broke mod_perl.]

* We have tried not redefining any Exxx constants\, but that requires Winsock error codes to be mapped to POSIX error codes in $! in order to match the Exxx constants exported by Errno.pm/POSIX.pm (which we believed people would be testing $! against\, having encouraged that for many years). [This is the current situation\, but has broken AnyEvent\, although it was already broken for many years by the original Exxx->WSAExxx mapping.]

Regarding the first attempt\, there is the further possibility that we could map POSIX error codes to Winsock error codes without actually redefining the Exxx constants in errno.h (i.e. find all the places where something like ECONNABORTED is about to be assigned to $!/errno and assign WSAECONNABORTED instead\, but (1) that will still have the same problem in that C code needs updating as well as Perl code\, and will thus still cause breakage with mod_perl and other such libraries that don't play the same game\, and (2) there are a *lot* of places around the perl core code in which that needs doing; by contrast\, mapping the Winsock error codes to POSIX error codes was easily done in just a few places in two win32/ files).

The other idea (raised further below) is to restore Winsock error codes in $!\, don't redefine anything anywhere\, and export Exxx constants and WSAExxx constants separately\, but even that will break code that is testing $! against the Exxx constants exported by Errno.pm and POSIX.pm until it is changed to test against the new WSAExxx constants instead.

Can you think of any other solution here?

My worry about the latter approach (which is what you've suggested as a minimal partial solution to these issues) was that the Exxx constants are not only used in socket programming. If other (non-socket-related) CRT functions on Windows make use of some of the new errno.h constants (e.g. if some CRT function like fread() or system() happens to fail and set errno to one of the new Exxx values) then the corresponding check in a Perl program (comparing $! to the relevant Exxx constant) would then fail because the Exxx constant exposed by Perl will have been changed to a Winsock-related value.

This is what I call breaking things now in an attempt to prevent hypothetical future breakage.

Also\, converting CRT error codes to any Perl's code (such as WSA* ones) would address your concern as well\, without breaking the backward compatibility.

(This is covered by my comments above regarding our first attempt at a VC10 solution\, if I am understanding you correctly.)

But worse\, the Perl Posix error codes currently have the winsock semantics ($! = EINPROGRESS\, print $!; => "A blocking operation is currently executing." instead of "Operation now in progress"). So the future breakage that you tried to avoid already happens\, as the Posix error message is wrong. Maybe I am assuming too much that Windows Posix codes have Posix meaning. Maybe I see the glass half empty: on the other side\, you fixed the error message for those using EINPROGRESS with winsock on Windows.

Yes\, absolutely. As I've written above that's exactly what we we've been doing in the expectation that people would be using the Exxx constants with Winsock on Windows\, which is precisely why we were most concerned to keep that case working. Indeed\, there is a change (http://perl5.git.perl.org/perl.git/commit/364d54baf6) that explicitly made things like your example above work. The commit message ends by saying "This now works as expected:"

C:\git\perl>perl -Ilib -MPOSIX -E "$!=POSIX::EWOULDBLOCK; say $!" A non-blocking socket operation could not be completed immediately.

That is why I took the former approach instead\, which is a safe change except for the case where users test $! against hard-coded numbers like 10035 instead the Exxx constants.

Arguments have been given why using the Exxx constants to test winsock errors is potentially wrong. And Perl core does not provide constants for winsock\, leaving modules to use hard coded values. Knowing this\, I do not consider the change safe.

Our position in believing it to be safe was that Perl *does* provide constants for Winsock -- namely\, the Exxx constants exported by Errno.pm and POSIX.pm\, and even provides for correct stringification of them. This has all been done in good faith\, with much care for backwards compatibility\, and is only undone by the news that some Exxx error codes do not mean the same thing as like-named WSAExxx error codes. That is something that seems to have only come to light (on this mailing list\, at least) in the last week or two\, despite the questionable definitions of Exxx constants exported by Errno.pm having been in place since 2002.

I'm sure that if this problem had come to light years ago\, such that by now Errno.pm and POSIX.pm were littered with definitions of Exxx constants as differently-named WSAExxx constants\, then that information would have been taken into account when deciding how best to support VC10.

Finally\, on the subject of EINPROGRES vs WSAEINPROGRESS I would also note that EINPROGRESS applies to non-blocking connections\, while WSAEINPROGRESS applies to blocking connections. So not only do they

have opposite meaning (success vs failure)\, they are also used in different contexts. Does this fact help to find a workaround with current perls? I.e. If you handle blocking and non-blocking connections separately then are you able to unambiguously test for one condition or the other without getting an accidental "false postiive"? I have no deep knowledge in this area\, it's just a thought that struck me as something that might be worth exploring.

Neither do I have deep knowledge on this. Though\, affecting 2 different semantics to the same code depending on the OS is really bad. If ever Windows starts to use Posix code for their Posix meaning\, you will be in a bad situation\, as currently you are attaching the Winsock sementics to those codes.

Yes\, that is true :-/

The only really robust solution that I have in mind right now for how to solve all of this is to have a Perl module that explicitly exports

Using WSA* code as in previous Perl versions is not as robust\, but at least is more robust than the current solution.

the WSAExxx values in their own set of WSAExxx constants\, and change

That part is easy and does not break anything\, but the constants would be useless as long as the winsock calls are not setting those values.

Yes\, indeed. We would certainly have to revert to putting Winsock error codes back into $! in that case.

Errno.pm/POSIX.pm to only export the Exxx constants that are defined in errno.h. That\, of course\, would also cause a lot of upheaval for people\, having to adapt their code to use the new constants\, but would at least solve the problem once for all for the future.

That's the tricky part. Though\, it has been suggested that case could be made to merge WSA and Exxx codes when their semantics are matching and not incompatible (for concerned system calls). And you can decide what your Posix error codes are in Perl. They do not have to match exactly those of Windows. As said before\, if you find acceptable to translate WSA codes to Windows' Exxx ones\, I don't see why you could not conversely translate Windows' Exxx ones to WSA* if it works better.

(As noted earlier\, I think we've tried this both ways now and come unstuck both times.)

Obviously\, doing things like keeping Perl's EWOULDBLOCK equal to WSAEWOULDBLOCK (more importantly: letting winsock calls return winsock errors) would restore the backward compatibility as it was before the change.

Regards\,

-- Laurent

p5pRT commented 9 years ago

From @Leont

On Thu\, Mar 19\, 2015 at 7:11 PM\, Laurent \laurent\.aml@gmail\.com wrote:

Errno.pm/POSIX.pm to only export the Exxx constants that are defined

in errno.h. That\, of course\, would also cause a lot of upheaval for people\, having to adapt their code to use the new constants\, but would at least solve the problem once for all for the future.

That's the tricky part. Though\, it has been suggested that case could be made to merge WSA and Exxx codes when their semantics are matching and not incompatible (for concerned system calls). And you can decide what your Posix error codes are in Perl. They do not have to match exactly those of Windows. As said before\, if you find acceptable to translate WSA codes to Windows' Exxx ones\, I don't see why you could not conversely translate Windows' Exxx ones to WSA* if it works better. Obviously\, doing things like keeping Perl's EWOULDBLOCK equal to WSAEWOULDBLOCK (more importantly: letting winsock calls return winsock errors) would restore the backward compatibility as it was before the change.

Maybe I'm saying something stupid here\, but I would expect $! to do the portable EFOO thing and $^E the platform specific WSAE errors.

Leon

p5pRT commented 9 years ago

From @steve-m-hay

On 20 March 2015 at 10:00\, Leon Timmermans \fawaka@gmail\.com wrote:

On Thu\, Mar 19\, 2015 at 7:11 PM\, Laurent \laurent\.aml@gmail\.com wrote:

Errno.pm/POSIX.pm to only export the Exxx constants that are defined in errno.h. That\, of course\, would also cause a lot of upheaval for people\, having to adapt their code to use the new constants\, but would at least solve the problem once for all for the future.

That's the tricky part. Though\, it has been suggested that case could be made to merge WSA and Exxx codes when their semantics are matching and not incompatible (for concerned system calls). And you can decide what your Posix error codes are in Perl. They do not have to match exactly those of Windows. As said before\, if you find acceptable to translate WSA codes to Windows' Exxx ones\, I don't see why you could not conversely translate Windows' Exxx ones to WSA* if it works better. Obviously\, doing things like keeping Perl's EWOULDBLOCK equal to WSAEWOULDBLOCK (more importantly: letting winsock calls return winsock errors) would restore the backward compatibility as it was before the change.

Maybe I'm saying something stupid here\, but I would expect $! to do the portable EFOO thing and $^E the platform specific WSAE errors.

Not a stupid thing to say at all. Perl functions wrapping CRT functions (which in turn wrap Win32 API functions) work put errno into $! and GetLastError() into $^E so you might expect errno in $! and WSAGetLastError() in $^E from Winsock functions\, but according to https://msdn.microsoft.com/en-us/library/windows/desktop/ms737828%28v=vs.85%29.aspx, "Error codes set by Windows Sockets are not made available through the errno variable."

The same page also notes that\, "early versions of Windows (Windows 95 with the Windows Socket 2 Update and Windows 98\, for example) redefined regular Berkeley error constants typically found in errno.h on BSD as the equivalent Windows Sockets WSA errors. So for example\, ECONNREFUSED was defined as WSAECONNREFUSED in the Winsock.h header file."

This may explain why WSAGetLastError() codes have long been put into $! and why the original Exxx->WSAExxx mapping was done in Errno.pm.

In retrospect it's easy to say that it would probably have made more sense to just put WSAGetLastError() codes into $^E\, and to scrap the Exxx->WSAExxx mapping since\, as that MSDN page goes on to say\, "In subsequent versions of Windows (Windows NT 3.1 and later) these defines were commented out to avoid conflicts with errno.h used with Microsoft C/C++ and Visual Studio."

I don't know where this all leaves us in our need to sort out backwards-compatibility woes\, though.

p5pRT commented 9 years ago

From laurent.aml@gmail.com

Steve\,

On Thu\, Mar 19\, 2015 at 8:18 PM\, Steve Hay \steve\.m\.hay@googlemail\.com wrote:

On 19 March 2015 at 18:11\, Laurent \laurent\.aml@gmail\.com wrote:

Morning\,

Evening ;-)

On Thu\, Mar 19\, 2015 at 5:47 AM\, Steve Hay \steve\.m\.hay@googlemail\.com wrote:

On 18 March 2015 at 23:44\, Laurent Aml via RT \<perlbug-comment@perl.org

wrote:

This ticket should be reopened; current Perl is broken regarding the handling of WSA* winsock errors. WSA* error names are not Posix. While some error codes with similar names may have similar meanings\, several of them have completely different ones. WSAEINPROGRESS for example\, when returned from connect() implies that the connect failed\, while for Posix\, EINPROGRESS means the connect is ongoing. So using Posix codes in place of WSA* one looks like a recipe for disaster\, and one should not expect others to consider this a good practice.

Secondly\, the change of the EWOULBLOCK value to 140 is a Perl decision\, not dictated by VC 2010. Windows still uses 10035 for WSAEWOULDBLOCK (and returns that from winsock). VC 2010 certainly defines EWOULDBLOCK as 140\, but I don't see how this particular EWOULDBLOCK is of any use in Perl? Though\, doing this has intentionally introduced backward compatibility issues\, to prevent some hypothetical future breakage. At least\, I think Perl should revert back to using WSA* values as in previous Perl versions\, to fix the current issue. While not fixing the mix of WSA*/Posix codes with incompatible meanings\, it would prevent some backward compatibility issues\, without much (if any?) drawback.

It is also worth noting that AnyEvent has been subtly broken for years on non-cygwin Windows Perl because EINPROGRESS has been mapped to WSAEINPROGRESS.

Finally\, Marc Lehmann is much more knowledgeable than me on the subject. The above technical findings are his. Please refer to the perl5-porters or AnyEvent mailing lists for more details.

The non-equivalence of like-named Winsock/POSIX error codes appears not to be widely known. Several commits over the years (first in Errno.pm in 5.8\, then in POSIX.pm in 5.12\, and more recently in some win32/ functions in 5.20) have not shown any awareness of this\, and from Googling around it is clear that numerous other scripting languages (PHP\, Python\, Ruby and Tcl) and other open source projects appear to set up similar equivalences.

It was on this basis that it was assumed that anyone wishing to test whether a Winsock error was WSAEWOULDBLOCK would use the EWOULDBLOCK

Now that we know that the basis is false\, what has been deducted from it is no more relevant.

But it is relevant for explaining the decisions taken: If you look at what was done whilst keeping in mind what we believed to be true then you will see that the actions taken were precisely because we *do* very much have a care for backwards compatibility. It does rather irk me that the idea of us not caring about backwards compatibility keeps being aired. The breakage was caused because the initial understanding was wrong; not because we didn't care.

I am not convinced the backward compatibility breakage was sufficiently motivated. It may be easy to point that out after the fact\, but it boils down to the following: The compatibility has been broken because MS added some #define\, not even used by MS itself. How can some #define\, intended for preprocessing only\, have an impact in the compiled Perl strong enough to justify a compatibility breakage in pure perl modules? Many C programs made the shortcut of defining E* as WSA* when not already defined\, to get more compact code\, and they will all be fixed to take into account this new define. I am not sure why Perl tries to fix this whole mess at its level (eg rather than in XSs)\, especially detrimentally to its backward compatibility.

Also\, the supposition that everyone would use EWOULDBLOCK for winsock checks is far fetched: there is nothing in Perl doc (perlfunc\, perlport\, Socket at least) that suggests that. Actually\, I don't see where you would have encouraged that. And Windows Perl is very windows-ish... it does not try to provide a reliable Posix abstraction as cyngwin does.

[...]

It is true that we could always set EWOULDBLOCK to the WSAEWOULDBLOCK

And this is what Perl had been doing happily for years.

You've cut off the second half of my sentence there. Perl has not

I did so\, just to point out something related\, not to reinterpret what you wrote out of context.

previously been setting EWOULDBLOCK to WSAEWOULDBLOCK *when errno.h gives us a value already*. It's only previously set EWOULDBLOCK to WSAEWOULDBLOCK when no natural value to use was already in the system.

value\, even when errno.h gives us a value already\, but this raises the question of what is expected of the constants exported by Errno.pm/POSIX.pm: Should they generally reflect the errno.h values of the compiler used as far as possible (and only use Winsock values for those that are still not in errno.h)\, or should they generally be set to like-named Winsock values wherever possible (and only retain their errno.h values where there is no like-named Winsock value)? (We would end up with a mix of both either way\, of course.)

The real issue is somewhere else actually. It does not really matter what values you choose for Perl Posix codes. The problem is that Winsock is now returning pseudo Posix codes\, instead of the WSA* one.

Now\, you don't mind breaking the backward compatibility for AnyEvent/IO::Socket as it did the thing right (not mixing WSA and Posix codes)\, but it appears you have a concern about breaking the compatibility for those that would use the Posix codes to test winsock errors: that's the only reason I figured out why you would have changed the winsock error codes at the same time you changed the Posix one.

I take exception with the first part of that paragraph. As I wrote above\, we certainly *do* mind breaking backwards compatibility\, and strove very hard not to do so. We believed that people wishing to check for Winsock error codes such as WSAEWOULDBLOCK would do so on Windows by testing $! against EWOULDBLOCK: Facilitating that was presumably the intent of the original Errno.pm change (http://perl5.git.perl.org/perl.git/commit/4d70086c95) which first exported Errno::EWOULDBLOCK with the value set to WSAEWOULDBLOCK's value\, and since that first appeared in 5.8.0 in 2002 we assumed that the practice would be well established by now.

Indeed\, we seem to have further encouraged people to check for Winsock errors by testing $! against Exxx constants by exporting the same Winsock-valued Exxx constants from POSIX.pm as of 5.12 (http://perl5.git.perl.org/perl.git/commit/2489f03d17) as well. I imagine the thinking behind those changes was (ironically\, it would now appear) that this would make writing portable code easier: One could simply test $! against Exxx constants exported from either Errno.pm or POSIX.pm on all platforms\, instead of having to do that on *nix and muck around with different values on Windows. Obviously that breaks down if the values thus put into various Exxx constants mean different things on *nix and Windows\, but since that wasn't known to us at the time it couldn't have been accounted for.

I am not retrospectively judging whether assigning WSA* to E* was a good/bad thing. I can't tell if there was practical issues assigning WSAEWOULDBLOCK to EWOULDBLOCK\, when EWOULDBLOCK was not defined. (Though we know now that INPROGRESS association is bad). And given the wide use of such approximation\, I would rather consider that as part of the backward compatibility to maintain (as long as the association still makes sense).

That's not fair. Especially as the solution is obvious: using WSA values for Perl Posix codes keeps the backward compatibility for both.

If I understand you correctly\, you are suggesting that we should do this:

#ifdef EWOULDBLOCK #undef EWOULDBLOCK #endif #define EWOULDBLOCK WSAEWOULDBLOCK

and keep Winsock error codes in $!.

This is indeed apparently the most obvious solution\, and was actually the first approach that was attempted when trying to fix the VC10 build. It was done in commit http://perl5.git.perl.org/perl.git/commit/b59e75b34c for both Errno.pm and POSIX.pm\, but that lead to conflict within the perl core (the C code) because the values it was using for the Exxx constants affected were then out of sync with the values exported by Errno.pm and POSIX.pm. Thus\, C code putting ECONNABORTED into errno would yield a different value in $! (namely\, 106) compared to Perl code putting ECONNABORTED into $! (namely\, 10053).

Therefore\, a follow-up commit (http://perl5.git.perl.org/perl.git/commit/912c63ed00) additionally redefined those Exxx constants that the perl core used in the same manner as was done above for Errno.pm/POSIX.pm\, but now in the C code of the perl core too (in an installed header file\, for the benefit of XS code that might also assign POSIX error codes to errno; arguably the change should have redefined all the Exxx values that Errno.pm/POSIX.pm redefined\, rather than restricting itself to only those few used in the perl core).

So that is the obvious solution\, and I find reassuring you tested it first.

However\, this resulted in compatibility problems with other libraries. Specifically\, breakage was found in mod_perl: Apache httpd obviously uses the standard errno.h value of 106 for ECONNABORTED\, but XS modules picked up perl's redefined errno.h value of 10053\, leading to a failure to recognize some errno values set by httpd.

What was mod_perl returning before (and still does with an older compiler\, I guess)? WSA* values. It looks like mod_perl broke its backward compatibility with (Windows) Perl.

The issue is wider than that... XS modules compiled with different compilers may return different error codes\, and I don't think Perl imposes to use a specific compiler version when compiling XS modules (even though their are pitfalls doing so)? What about some XS module returning a WSA* code (as it used to)\, and failing comparisons with E* counterparts?

This is why it was decided to jump the other way instead\, changing the values put into $! and changing the values of the Exxx constants to match\, believing that that's what people would be testing $! against. You can read the full gory details in the merge commit http://perl5.git.perl.org/perl.git/commit/ea95436966 and the 11 commits before it (which constitute what was merged in).

So to me the solution here is not at all obvious:

* We have tried redefining Exxx constants to WSAExxx values\, but that needs doing in C code as well as Perl code\, and the former conflicts when linking against other C libraries that were not built with similarly redefined Exxx constants. [This was the first attempt\, which broke mod_perl.]

* We have tried not redefining any Exxx constants\, but that requires Winsock error codes to be mapped to POSIX error codes in $! in order to match the Exxx constants exported by Errno.pm/POSIX.pm (which we believed people would be testing $! against\, having encouraged that for many years). [This is the current situation\, but has broken AnyEvent\, although it was already broken for many years by the original Exxx->WSAExxx mapping.]

Regarding the first attempt\, there is the further possibility that we could map POSIX error codes to Winsock error codes without actually redefining the Exxx constants in errno.h (i.e. find all the places where something like ECONNABORTED is about to be assigned to $!/errno and assign WSAECONNABORTED instead\, but (1) that will still have the same problem in that C code needs updating as well as Perl code\, and will thus still cause breakage with mod_perl and other such libraries that don't play the same game\, and (2) there are a *lot* of places around the perl core code in which that needs doing; by contrast\, mapping the Winsock error codes to POSIX error codes was easily done in just a few places in two win32/ files).

The other idea (raised further below) is to restore Winsock error codes in $!\, don't redefine anything anywhere\, and export Exxx constants and WSAExxx constants separately\, but even that will break code that is testing $! against the Exxx constants exported by Errno.pm and POSIX.pm until it is changed to test against the new WSAExxx constants instead.

Can you think of any other solution here?

With the current situation\, Perl versions compiled with different compilers will have different error codes\, and different breakages with this or that Perl program\, cpan module or XS codes\, themselves possibly compiled with even different compilers. The binary compatibility among all those things is completely broken\, and I don't believe there will be a solution that could be localized to Perl core only. I guess this is why you failed to replicate the initial AnyEvent issue: a newer Perl with an older compiler still using EWOULDBLOCK=WSAEWOULDBLOCK.

One suggestion is: - Revert back to using WSA* values for Perl's compatible E* codes\, to restore backward compatibility. This applies to WSA/E code having close enough semantics (eg: WSAEWOULDBLOCK/EWOULDBLOCK/EAGAIN) only\, to favor backward compatibility\, possibly over correctness. - Other incompatible WSA/E codes should be split (eg: EINPROGRESS)\, and modules using one for the other\, being already broken anyway\, will have to be fixed. - expect XS modules to maintain their backward compatibility\, that is: return WSA* values as they did before\, independently of the compiler they are using. This is the strongest requirement\, but XS code is not different than any other C code that relied on the WSA/E associations\, and there is no reason to consider they are not broken and push the fault to Perl. They are providing different error codes depending on the compiler => they fail to provide a stable binary compatibility to Perl => they have to be fixed. - provide WSA* Perl constants to help in the process (and document when WSAxxx=Exxx or not) - suggest to use compilers without the new E* constants defined for modules not yet fixed.

The above proposal fixes the compatibility issues and the WSA/E incompatibilities for all fixed Perl versions\, independently of the compilers. Such a solution aims at maintaining backward compatibility\, and is no more detrimental to correctness then the current solution. However\, it forces XS modules to get fixed\, which seems to have been a concern more important than backward compatibility.

Then\, I am not sure it would be required to fully split WSA/E codes. At least not yet\, as the new Windows E* codes are currently good for nothing (except creating a mess). Also\, given that Perl created a de facto E* values assigment with WSA codes\, potentially different from the E* constants defined by the compiler\, that cannot be modified without somehow breaking the backward compatibility\, it seems Perl would need some abstraction layer between Perl and XS for $!. Possibly a few CPP macros to explicitly switch from Perl to C values and inversely. Also\, I am not familiar with Perl core code\, so I am certainly overlooking a lot of details\, or more subtle alternatives.

Another solution is to wrap winsock in a Posix abstraction layer: make it return fully Posix compliant codes (eg. so WSAEWOULDBLOCK returns EAGAIN for non-blocking send/recv and EINPROGRESS for connect\, ...). So building on top of the current solution. That would still break compatibility with Windows-only code using WSA* hardcoded constants (or XS code using winsock directly and assigning WSA* to $!)\, but could maintain it with BSD socket code. At least\, the breakage should be less important than now. Returning WSAEINPROGRESS (!= EINPROGRESS) could still be done as well\, to deal with Windows specific oddities (or use EAGAIN in the specific case of connect?). The advantage is to keep a compiler's Es to Perl's Es strong coupling\, which would avoid a Windows-specific mapping for XS modules. I can't tell whether such a solution is realistic\, however.

Perl is schizophrenic here: it tries to stick to low level interfaces (winsock returned bare WSA codes) on one hand\, but to create a broken WSA/E pseudo-abstraction in $! on the other hand. Either it's OK to have an abstraction\, or it's not\, but this middle ground situation seems difficult to hold.

The last solution I see is to give up on the WSA* to E* mapping\, which breaks all modules using E* codes with winsock. It's hard to say to what extend modules doing so are already broken (given then non-posix behavior of winsock). I mean\, from a practical perspective\, as the winsock/posix E* mix as it is\, is already broken by design.

I guess using Perl 5.18 with a compiler without the new E* values is the best backward compatible solution at the moment.

-- Laurent

p5pRT commented 9 years ago

From @steve-m-hay

On 24 March 2015 at 15:43\, Laurent \laurent\.aml@gmail\.com wrote:

Steve\,

On Thu\, Mar 19\, 2015 at 8:18 PM\, Steve Hay \steve\.m\.hay@googlemail\.com wrote:

On 19 March 2015 at 18:11\, Laurent \laurent\.aml@gmail\.com wrote:

Morning\,

Evening ;-)

On Thu\, Mar 19\, 2015 at 5:47 AM\, Steve Hay \steve\.m\.hay@googlemail\.com wrote:

On 18 March 2015 at 23:44\, Laurent Aml via RT \perlbug\-comment@perl\.org wrote:

This ticket should be reopened; current Perl is broken regarding the handling of WSA* winsock errors. WSA* error names are not Posix. While some error codes with similar names may have similar meanings\, several of them have completely different ones. WSAEINPROGRESS for example\, when returned from connect() implies that the connect failed\, while for Posix\, EINPROGRESS means the connect is ongoing. So using Posix codes in place of WSA* one looks like a recipe for disaster\, and one should not expect others to consider this a good practice.

Secondly\, the change of the EWOULBLOCK value to 140 is a Perl decision\, not dictated by VC 2010. Windows still uses 10035 for WSAEWOULDBLOCK (and returns that from winsock). VC 2010 certainly defines EWOULDBLOCK as 140\, but I don't see how this particular EWOULDBLOCK is of any use in Perl? Though\, doing this has intentionally introduced backward compatibility issues\, to prevent some hypothetical future breakage. At least\, I think Perl should revert back to using WSA* values as in previous Perl versions\, to fix the current issue. While not fixing the mix of WSA*/Posix codes with incompatible meanings\, it would prevent some backward compatibility issues\, without much (if any?) drawback.

It is also worth noting that AnyEvent has been subtly broken for years on non-cygwin Windows Perl because EINPROGRESS has been mapped to WSAEINPROGRESS.

Finally\, Marc Lehmann is much more knowledgeable than me on the subject. The above technical findings are his. Please refer to the perl5-porters or AnyEvent mailing lists for more details.

The non-equivalence of like-named Winsock/POSIX error codes appears not to be widely known. Several commits over the years (first in Errno.pm in 5.8\, then in POSIX.pm in 5.12\, and more recently in some win32/ functions in 5.20) have not shown any awareness of this\, and from Googling around it is clear that numerous other scripting languages (PHP\, Python\, Ruby and Tcl) and other open source projects appear to set up similar equivalences.

It was on this basis that it was assumed that anyone wishing to test whether a Winsock error was WSAEWOULDBLOCK would use the EWOULDBLOCK

Now that we know that the basis is false\, what has been deducted from it is no more relevant.

But it is relevant for explaining the decisions taken: If you look at what was done whilst keeping in mind what we believed to be true then you will see that the actions taken were precisely because we *do* very much have a care for backwards compatibility. It does rather irk me that the idea of us not caring about backwards compatibility keeps being aired. The breakage was caused because the initial understanding was wrong; not because we didn't care.

I am not convinced the backward compatibility breakage was sufficiently motivated. It may be easy to point that out after the fact\, but it boils down to the following: The compatibility has been broken because MS added some #define\, not even used by MS itself. How can some #define\, intended for preprocessing only\, have an impact in the compiled Perl strong enough to justify a compatibility breakage in pure perl modules? Many C programs made the shortcut of defining E* as WSA* when not already defined\, to get more compact code\, and they will all be fixed to take into account this new define. I am not sure why Perl tries to fix this whole mess at its level (eg rather than in XSs)\, especially detrimentally to its backward compatibility.

The breakage (in code testing $! against Winsock codes like 10053 rather than against Exxx constants) occurred because the initial attempt at fixing the build with VC10 (i.e. the solution mentioned further below\, which seemed like the "obvious" solution) didn't work out. It's not exactly "motivation" for breaking compatibility; nobody wanted to do that\, but after trying the seemingly obvious solution and finding that it didn't work\, this was the result\, which was agreed to be acceptable in the absence of any better suggestions. If there are better solutions on the table now then we are certainly keen to examine them\, and I thank you for your suggestions below.

It may seem a little strange that new #defines in errno.h have an effect on pure Perl code\, but it's a result of perl doing just what other C programs have done (namely\, #defining E* as WSA* when not already #defined) but then also exposing those E* constants to pure Perl code via Errno.pm. So changes in the E* constants in errno.h imply changes in the E* constants exposed to Perl code (unless Errno.pm more aggressively re#defines them to keep them as they were -- which is what the first attempt did\, and failed because of exactly that...).

Also\, the supposition that everyone would use EWOULDBLOCK for winsock checks is far fetched: there is nothing in Perl doc (perlfunc\, perlport\, Socket at least) that suggests that. Actually\, I don't see where you would have encouraged that. And Windows Perl is very windows-ish... it does not try to provide a reliable Posix abstraction as cyngwin does.

[...]

It is true that we could always set EWOULDBLOCK to the WSAEWOULDBLOCK

And this is what Perl had been doing happily for years.

You've cut off the second half of my sentence there. Perl has not

I did so\, just to point out something related\, not to reinterpret what you wrote out of context.

previously been setting EWOULDBLOCK to WSAEWOULDBLOCK *when errno.h gives us a value already*. It's only previously set EWOULDBLOCK to WSAEWOULDBLOCK when no natural value to use was already in the system.

value\, even when errno.h gives us a value already\, but this raises the question of what is expected of the constants exported by Errno.pm/POSIX.pm: Should they generally reflect the errno.h values of the compiler used as far as possible (and only use Winsock values for those that are still not in errno.h)\, or should they generally be set to like-named Winsock values wherever possible (and only retain their errno.h values where there is no like-named Winsock value)? (We would end up with a mix of both either way\, of course.)

The real issue is somewhere else actually. It does not really matter what values you choose for Perl Posix codes. The problem is that Winsock is now returning pseudo Posix codes\, instead of the WSA* one.

Now\, you don't mind breaking the backward compatibility for AnyEvent/IO::Socket as it did the thing right (not mixing WSA and Posix codes)\, but it appears you have a concern about breaking the compatibility for those that would use the Posix codes to test winsock errors: that's the only reason I figured out why you would have changed the winsock error codes at the same time you changed the Posix one.

I take exception with the first part of that paragraph. As I wrote above\, we certainly *do* mind breaking backwards compatibility\, and strove very hard not to do so. We believed that people wishing to check for Winsock error codes such as WSAEWOULDBLOCK would do so on Windows by testing $! against EWOULDBLOCK: Facilitating that was presumably the intent of the original Errno.pm change (http://perl5.git.perl.org/perl.git/commit/4d70086c95) which first exported Errno::EWOULDBLOCK with the value set to WSAEWOULDBLOCK's value\, and since that first appeared in 5.8.0 in 2002 we assumed that the practice would be well established by now.

Indeed\, we seem to have further encouraged people to check for Winsock errors by testing $! against Exxx constants by exporting the same Winsock-valued Exxx constants from POSIX.pm as of 5.12 (http://perl5.git.perl.org/perl.git/commit/2489f03d17) as well. I imagine the thinking behind those changes was (ironically\, it would now appear) that this would make writing portable code easier: One could simply test $! against Exxx constants exported from either Errno.pm or POSIX.pm on all platforms\, instead of having to do that on *nix and muck around with different values on Windows. Obviously that breaks down if the values thus put into various Exxx constants mean different things on *nix and Windows\, but since that wasn't known to us at the time it couldn't have been accounted for.

I am not retrospectively judging whether assigning WSA* to E* was a good/bad thing. I can't tell if there was practical issues assigning WSAEWOULDBLOCK to EWOULDBLOCK\, when EWOULDBLOCK was not defined. (Though we know now that INPROGRESS association is bad). And given the wide use of such approximation\, I would rather consider that as part of the backward compatibility to maintain (as long as the association still makes sense).

That's not fair. Especially as the solution is obvious: using WSA values for Perl Posix codes keeps the backward compatibility for both.

If I understand you correctly\, you are suggesting that we should do this:

#ifdef EWOULDBLOCK #undef EWOULDBLOCK #endif #define EWOULDBLOCK WSAEWOULDBLOCK

and keep Winsock error codes in $!.

This is indeed apparently the most obvious solution\, and was actually the first approach that was attempted when trying to fix the VC10 build. It was done in commit http://perl5.git.perl.org/perl.git/commit/b59e75b34c for both Errno.pm and POSIX.pm\, but that lead to conflict within the perl core (the C code) because the values it was using for the Exxx constants affected were then out of sync with the values exported by Errno.pm and POSIX.pm. Thus\, C code putting ECONNABORTED into errno would yield a different value in $! (namely\, 106) compared to Perl code putting ECONNABORTED into $! (namely\, 10053).

Therefore\, a follow-up commit (http://perl5.git.perl.org/perl.git/commit/912c63ed00) additionally redefined those Exxx constants that the perl core used in the same manner as was done above for Errno.pm/POSIX.pm\, but now in the C code of the perl core too (in an installed header file\, for the benefit of XS code that might also assign POSIX error codes to errno; arguably the change should have redefined all the Exxx values that Errno.pm/POSIX.pm redefined\, rather than restricting itself to only those few used in the perl core).

So that is the obvious solution\, and I find reassuring you tested it first.

However\, this resulted in compatibility problems with other libraries. Specifically\, breakage was found in mod_perl: Apache httpd obviously uses the standard errno.h value of 106 for ECONNABORTED\, but XS modules picked up perl's redefined errno.h value of 10053\, leading to a failure to recognize some errno values set by httpd.

What was mod_perl returning before (and still does with an older compiler\, I guess)? WSA* values. It looks like mod_perl broke its backward compatibility with (Windows) Perl.

mod_perl didn't change in this area. The breakage was caused by the re#definition of E* constants in that first attempt at VC10 support in perl:

Apache is compiled with no E* constants re#defined from their standard errno.h values. For portability\, it returns socket errors in APR_E* constants\, which are #defined as the corresponding E* constants if available\, or else are filled in with other values. So when Apache is compiled with VC10\, APR_ECONNABORTED is 106 (from the new ECONNABORTED in errno.h).

However\, mod_perl's XS components are compiled in the presence of perl header files\, one of which re#defined ECONNABORTED to WSAECONNABORTED (in order to maintain compatibility with the value that was previously filled in for builds using \<=VC9)\, so in these components APR_ECONNABORTED is now 10053\, causing tests against return values coming form Apache functions to fail.

What has mod_perl done wrong there?! It simply links in Apache library functions\, calls them and compares their return values to APR_E* constants\, which have been compiled into the XS components from Apache header files... and goes wrong because the APR_E* constants\, being dependent on the system's E* constants\, have been quietly changed in the process by perl's re#definition of the E* constants from errno.h.

You may point out that Apache are providing different error codes depending on the compiler\, but that doesn't matter to anyone that is carefully using the APR_E* constants\, not testing hard-coded numbers. The problem is that perl's aggressive re#definition of E* constants inadvertently affects those APR_E* constants themselves\, leaving mod_perl broken through no fault of its own.

That's why I really don't like re#defining E* constants\, which was an essential part of the first attempt\, and why it was abandoned.

By contrast\, the second attempt causes no interference in C-level E* constants and no breakage for pure Perl authors who are using the E* constants rather than hard-coded Winsock error codes.

I see that it has problems too\, but I think they mostly stem back to the introduction of the original E*->WSA* mapping\, so are of long standing anyway.

The issue is wider than that... XS modules compiled with different compilers may return different error codes\, and I don't think Perl imposes to use a specific compiler version when compiling XS modules (even though their are pitfalls doing so)?

This is true. bulk88 already raised the point that different error codes are now returned for different compilers\, which I agree may be undesirable\, but (as seen above)\, we are not alone in doing that either: Apache\, at least\, do the same with their APR_E* constants. That could possibly be avoided under a slight variant of the current design by defining EWOULDBLOCK et al for VC9 to be the values that VC10 has given them\, rather than giving them their like-named WSA* constant values. (I haven't thought through the implications of doing that yet. It's just another idea amongst many.)

What about some XS module returning a WSA* code (as it used to)\, and failing comparisons with E* counterparts?

Yes\, that would break\, but normally one puts the error code into errno/$! (where it gets intercepted and converted to an E* value) and tests that against E* constants.

This is why it was decided to jump the other way instead\, changing the values put into $! and changing the values of the Exxx constants to match\, believing that that's what people would be testing $! against. You can read the full gory details in the merge commit http://perl5.git.perl.org/perl.git/commit/ea95436966 and the 11 commits before it (which constitute what was merged in).

So to me the solution here is not at all obvious:

* We have tried redefining Exxx constants to WSAExxx values\, but that needs doing in C code as well as Perl code\, and the former conflicts when linking against other C libraries that were not built with similarly redefined Exxx constants. [This was the first attempt\, which broke mod_perl.]

* We have tried not redefining any Exxx constants\, but that requires Winsock error codes to be mapped to POSIX error codes in $! in order to match the Exxx constants exported by Errno.pm/POSIX.pm (which we believed people would be testing $! against\, having encouraged that for many years). [This is the current situation\, but has broken AnyEvent\, although it was already broken for many years by the original Exxx->WSAExxx mapping.]

Regarding the first attempt\, there is the further possibility that we could map POSIX error codes to Winsock error codes without actually redefining the Exxx constants in errno.h (i.e. find all the places where something like ECONNABORTED is about to be assigned to $!/errno and assign WSAECONNABORTED instead\, but (1) that will still have the same problem in that C code needs updating as well as Perl code\, and will thus still cause breakage with mod_perl and other such libraries that don't play the same game\, and (2) there are a *lot* of places around the perl core code in which that needs doing; by contrast\, mapping the Winsock error codes to POSIX error codes was easily done in just a few places in two win32/ files).

The other idea (raised further below) is to restore Winsock error codes in $!\, don't redefine anything anywhere\, and export Exxx constants and WSAExxx constants separately\, but even that will break code that is testing $! against the Exxx constants exported by Errno.pm and POSIX.pm until it is changed to test against the new WSAExxx constants instead.

Can you think of any other solution here?

With the current situation\, Perl versions compiled with different compilers will have different error codes\, and different breakages with this or that Perl program\, cpan module or XS codes\, themselves possibly compiled with even different compilers. The binary compatibility among all those things is completely broken\, and I don't believe there will be a solution that could be localized to Perl core only. I guess this is why you failed to replicate the initial AnyEvent issue: a newer Perl with an older compiler still using EWOULDBLOCK=WSAEWOULDBLOCK.

By this I assume you are referring to your 11 Mar comment (https://rt.perl.org/Public/Bug/Display.html?id=121727#txn-1335204)? The problem there was not an older compiler\, it was the gcc in Strawberry Perl 5.20.2\, which has the new VC10 #defines in its errno.h (EWOULDBLOCK=140). The problem was that AnyEvent only checked for EAGAIN\, whereas syswrite callers should check both EAGAIN and EWOULDBLOCK. It's not just the POSIX standard which says this; Linux manpages say the same (e.g. http://linux.die.net/man/2/write). Doing so would fix that problem.

One suggestion is: - Revert back to using WSA* values for Perl's compatible E* codes\, to restore backward compatibility. This applies to WSA/E code having close enough semantics (eg: WSAEWOULDBLOCK/EWOULDBLOCK/EAGAIN) only\, to favor backward compatibility\, possibly over correctness. - Other incompatible WSA/E codes should be split (eg: EINPROGRESS)\, and modules using one for the other\, being already broken anyway\, will have to be fixed. - expect XS modules to maintain their backward compatibility\, that is: return WSA* values as they did before\, independently of the compiler they are using. This is the strongest requirement\, but XS code is not different than any other C code that relied on the WSA/E associations\, and there is no reason to consider they are not broken and push the fault to Perl. They are providing different error codes depending on the compiler => they fail to provide a stable binary compatibility to Perl => they have to be fixed. - provide WSA* Perl constants to help in the process (and document when WSAxxx=Exxx or not) - suggest to use compilers without the new E* constants defined for modules not yet fixed.

The above proposal fixes the compatibility issues and the WSA/E incompatibilities for all fixed Perl versions\, independently of the compilers. Such a solution aims at maintaining backward compatibility\, and is no more detrimental to correctness then the current solution. However\, it forces XS modules to get fixed\, which seems to have been a concern more important than backward compatibility.

Then\, I am not sure it would be required to fully split WSA/E codes. At least not yet\, as the new Windows E* codes are currently good for nothing (except creating a mess). Also\, given that Perl created a de facto E* values assigment with WSA codes\, potentially different from the E* constants defined by the compiler\, that cannot be modified without somehow breaking the backward compatibility\, it seems Perl would need some abstraction layer between Perl and XS for $!. Possibly a few CPP macros to explicitly switch from Perl to C values and inversely. Also\, I am not familiar with Perl core code\, so I am certainly overlooking a lot of details\, or more subtle alternatives.

Another solution is to wrap winsock in a Posix abstraction layer: make it return fully Posix compliant codes (eg. so WSAEWOULDBLOCK returns EAGAIN for non-blocking send/recv and EINPROGRESS for connect\, ...). So building on top of the current solution. That would still break compatibility with Windows-only code using WSA* hardcoded constants (or XS code using winsock directly and assigning WSA* to $!)\, but could maintain it with BSD socket code. At least\, the breakage should be less important than now. Returning WSAEINPROGRESS (!= EINPROGRESS) could still be done as well\, to deal with Windows specific oddities (or use EAGAIN in the specific case of connect?). The advantage is to keep a compiler's Es to Perl's Es strong coupling\, which would avoid a Windows-specific mapping for XS modules. I can't tell whether such a solution is realistic\, however.

Perl is schizophrenic here: it tries to stick to low level interfaces (winsock returned bare WSA codes) on one hand\, but to create a broken WSA/E pseudo-abstraction in $! on the other hand. Either it's OK to have an abstraction\, or it's not\, but this middle ground situation seems difficult to hold.

The last solution I see is to give up on the WSA* to E* mapping\, which breaks all modules using E* codes with winsock. It's hard to say to what extend modules doing so are already broken (given then non-posix behavior of winsock). I mean\, from a practical perspective\, as the winsock/posix E* mix as it is\, is already broken by design.

I guess using Perl 5.18 with a compiler without the new E* values is the best backward compatible solution at the moment.

Thank you again for these suggestions. My initial thoughts are:

- The first solution (putting Winsock codes back into $!) requires Errno/POSIX exported E* constants to be Winsock values too (otherwise we break code that DOES test against E* constants\, which we thought most code did)\, which in turn requires re#defined errno.h values at the C level\, which I'm not keen on at all. However\, this was the most obvious solution in both your eyes and ours\, so if there is some way to make this work without screwing things up at the C level then I would be most interested.

- The second solution (creating a better abstraction layer) also sounds promising but would require the deepest Winsock/POSIX socket programming knowledge\, and is surely beyond my talents. As you note\, it also doesn't fix code that tests against Winsock error codes.

- The third solution (dropping all E*/WSA* mappings) would again break all the code that tests against E* constants.

I will try to find time to digest these proposals properly\, and will certainly draw them to the attention of all relevant parties in deciding what to do about all of this.

-- Laurent

p5pRT commented 9 years ago

From @steve-m-hay

On 24 March 2015 at 15:43\, Laurent \laurent\.aml@gmail\.com wrote:

Also\, the supposition that everyone would use EWOULDBLOCK for winsock checks is far fetched: there is nothing in Perl doc (perlfunc\, perlport\, Socket at least) that suggests that. Actually\, I don't see where you would have encouraged that. And Windows Perl is very windows-ish... it does not try to provide a reliable Posix abstraction as cyngwin does.

I meant to respond to this last night too\, but missed it.

It's true that nothing in the expected places in perl's documentation mentions that E* constants should be used for Winsock error code checks\, but it's equally true that nothing mentions that Winsock error codes are put in $! in the first place. Perl's $! corresponds to C's errno\, and the C Winsock functions do not put their error codes into errno\, so that's not a very obvious thing for anyone to have expected either. Users could only have found that out empirically or by examining the source code\, and if they've done that for $! then it's just as easy to do for E* constants too\, which is what *nix code would be checking $! against already... Other users might never even have thought about it and just blindly used E* constants as they do on *nix -- (slightly misguided-) ease of portability with which I still think was surely the main reason that perl ever put Winsock codes into $! and E* constants to start with.

Searching through the documentation now\, though\, I do find one prominent reference to perl putting Winsock error codes into $!: perl5200delta\, which describes quite clearly the fact that it no longer does so for those error codes that can be mapped to like-named E* constants in errno.h\, and the fact that if one tests $! against the E* constants then there is practically no breakage. So it's not like these changes in (undocumented) behaviour were sprung upon people without warning.

Here's the full section from perl5200delta's Incompatible Change section\, which surely anyone upgrading to 5.20.0 would read carefully?:

=head2 Assignments of Windows sockets error codes to $! now prefer F\<errno.h> values over WSAGetLastError() values

In previous versions of Perl\, Windows sockets error codes as returned by WSAGetLastError() were assigned to $!\, and some constants such as ECONNABORTED\, not in F\<errno.h> in VC++ (or the various Windows ports of gcc) were defined to corresponding WSAE* values to allow $! to be tested against the E* constants exported by L\ and L\.

This worked well until VC++ 2010 and later\, which introduced new E* constants with values E\ 100 into F\<errno.h>\, including some being (re)defined by perl to WSAE* values. That caused problems when linking XS code against other libraries which used the original definitions of F\<errno.h> constants.

To avoid this incompatibility\, perl now maps WSAE* error codes to E* values where possible\, and assigns those values to $!. The E* constants exported by L\ and L\ are updated to match so that testing $! against them\, wherever previously possible\, will continue to work as expected\, and all E* constants found in F\<errno.h> are now exported from those modules with their original F\<errno.h> values.

In order to avoid breakage in existing Perl code which assigns WSAE* values to $!\, perl now intercepts the assignment and performs the same mapping to E* values as it uses internally when assigning to $! itself.

However\, one backwards-incompatibility remains: existing Perl code which compares $! against the numeric values of the WSAE* error codes that were previously assigned to $! will now be broken in those cases where a corresponding E* value has been assigned instead. This is only an issue for those E* values E\ 100\, which were always exported from L\ and L\ with their original F\<errno.h> values\, and therefore could not be used for WSAE* error code tests (e.g. WSAEINVAL is 10022\, but the corresponding EINVAL is 22). (E* values E\ 100\, if present\, were redefined to WSAE* values anyway\, so compatibility can be achieved by using the E* constants\, which will work both before and after this change\, albeit using different numeric values under the hood.)

p5pRT commented 9 years ago

From rosiejjjj@outlook.com

Steve Hay wrote:

mod_perl didn't change in this area. The breakage was caused by the re#definition of E* constants in that first attempt at VC10 support in perl:

Apache is compiled with no E* constants re#defined from their standard errno.h values. For portability\, it returns socket errors in APR_E* constants\, which are #defined as the corresponding E* constants if available\, or else are filled in with other values. So when Apache is compiled with VC10\, APR_ECONNABORTED is 106 (from the new ECONNABORTED in errno.h).

However\, mod_perl's XS components are compiled in the presence of perl header files\, one of which re#defined ECONNABORTED to WSAECONNABORTED (in order to maintain compatibility with the value that was previously filled in for builds using \<=VC9)\, so in these components APR_ECONNABORTED is now 10053\, causing tests against return values coming form Apache functions to fail.

So basically\, any .dll compiled with >= VC 2010\, which is libc/MS CRT aware\, is not ABI compatible with\, \<= VC 2008?

Here is a question\, has MS made any comments on why they messed up the definitions of E* constants\, when MS's business model is ABI compatibility [of typically closed source software]\, for forever?

My understand is poor\, do the Winsock APIs actually return the 100-200 series errors or not? Or is no known use of those 100-200 class Winsock-ish E* constants by MS and they were added by a rogue (or freelance) VC dev?

What has mod_perl done wrong there?! It simply links in Apache library functions\, calls them and compares their return values to APR_E* constants\, which have been compiled into the XS components from Apache header files... and goes wrong because the APR_E* constants\, being dependent on the system's E* constants\, have been quietly changed in the process by perl's re#definition of the E* constants from errno.h.

You may point out that Apache are providing different error codes depending on the compiler\, but that doesn't matter to anyone that is carefully using the APR_E* constants\, not testing hard-coded numbers. The problem is that perl's aggressive re#definition of E* constants inadvertently affects those APR_E* constants themselves\, leaving mod_perl broken through no fault of its own.

p5pRT commented 9 years ago

From rosiejjjj@outlook.com

Steve Hay wrote:

mod_perl didn't change in this area. The breakage was caused by the re#definition of E* constants in that first attempt at VC10 support in perl:

Apache is compiled with no E* constants re#defined from their standard errno.h values. For portability\, it returns socket errors in APR_E* constants\, which are #defined as the corresponding E* constants if available\, or else are filled in with other values. So when Apache is compiled with VC10\, APR_ECONNABORTED is 106 (from the new ECONNABORTED in errno.h).

However\, mod_perl's XS components are compiled in the presence of perl header files\, one of which re#defined ECONNABORTED to WSAECONNABORTED (in order to maintain compatibility with the value that was previously filled in for builds using \<=VC9)\, so in these components APR_ECONNABORTED is now 10053\, causing tests against return values coming form Apache functions to fail.

So basically\, any .dll compiled with >= VC 2010\, which is libc/MS CRT aware\, is not ABI compatible with\, \<= VC 2008?

What has mod_perl done wrong there?! It simply links in Apache library functions\, calls them and compares their return values to APR_E* constants\, which have been compiled into the XS components from Apache header files... and goes wrong because the APR_E* constants\, being dependent on the system's E* constants\, have been quietly changed in the process by perl's re#definition of the E* constants from errno.h.

You may point out that Apache are providing different error codes depending on the compiler\, but that doesn't matter to anyone that is carefully using the APR_E* constants\, not testing hard-coded numbers. The problem is that perl's aggressive re#definition of E* constants inadvertently affects those APR_E* constants themselves\, leaving mod_perl broken through no fault of its own.

p5pRT commented 9 years ago

From @steve-m-hay

On 26 March 2015 at 09:59\, bulk 88 \rosiejjjj@outlook\.com wrote:

Steve Hay wrote:

mod_perl didn't change in this area. The breakage was caused by the re#definition of E* constants in that first attempt at VC10 support in perl:

Apache is compiled with no E* constants re#defined from their standard errno.h values. For portability\, it returns socket errors in APR_E* constants\, which are #defined as the corresponding E* constants if available\, or else are filled in with other values. So when Apache is compiled with VC10\, APR_ECONNABORTED is 106 (from the new ECONNABORTED in errno.h).

However\, mod_perl's XS components are compiled in the presence of perl header files\, one of which re#defined ECONNABORTED to WSAECONNABORTED (in order to maintain compatibility with the value that was previously filled in for builds using \<=VC9)\, so in these components APR_ECONNABORTED is now 10053\, causing tests against return values coming form Apache functions to fail.

So basically\, any .dll compiled with >= VC 2010\, which is libc/MS CRT aware\, is not ABI compatible with\, \<= VC 2008?

Here is a question\, has MS made any comments on why they messed up the definitions of E* constants\, when MS's business model is ABI compatibility [of typically closed source software]\, for forever?

My understand is poor\, do the Winsock APIs actually return the 100-200 series errors or not? Or is no known use of those 100-200 class Winsock-ish E* constants by MS and they were added by a rogue (or freelance) VC dev?

MS haven't changed any existing E* constants; they've only added new ones. That doesn't make it ABI incompatible to my mind.

I've not heard of any cases of Winsock functions using these new E* constants in VC10+. As far as I know\, WSAGetLastError() always still returns the usual WSAE* constants.

So I think problems only arise for applications that #define "missing" E* constants as WSAE* values: MS now #define some of those formerly missing E* constants themselves (with non-WSAE* values)\, causing conflicts and backwards-compatibility issues. MS have noted (at https://msdn.microsoft.com/en-us/library/windows/desktop/ms737828%28v=vs.85%29.aspx) that they used to make the same E*=WSAE* #definitions themselves in Winsock2.h\, but that is now commented-out and they discourage uncommenting that block. (I think the mapping originally existed to ease porting of *nix programs to Winsock\, but the mapping shows no awareness of the differences that have come to light in some like-named E*/WSAE* constants\, e.g. it includes #define EINPROGRESS WSAEINPROGRESS itself!) So this E*=WSAE* thing is perhaps best described as historical baggage.

I doubt if there is any way to fix all the issues with $!/E* that have been raised here without upsetting somebody somewhere\, and I'm currently thinking that the best way to fix it might be to officially deprecate the use of $!/E* for testing socket errors on Windows and start putting WSAGetLastError() codes into $^E\, perhaps with WSAE* constants exported by Errno.pm and POSIX.pm on Windows.

Users would then have to check $! against E* on most systems\, but $^E against WSAE* on Windows. That's rather out of keeping with how CRT functions are wrapped by perl built-ins\, but no worse than checking $! against hard-coded Winsock error codes and/or different E* constants for Windows only.

I think the confusion in where to put Winsock error codes arises because Winsock functions like accept()\, connect() and select() correspond to functions available on other OSes\, so they are not OS-specific and you might expect error codes in $! (as for CRT functions)\, and yet (unlike CRT functions) they do not actually set the C errno variable which $! is intended to correspond to\, and in fact don't return POSIX E* error codes at all.

p5pRT commented 9 years ago

From @ap

* Steve Hay \steve\.m\.hay@googlemail\.com [2015-03-25 04:25]:

- The second solution (creating a better abstraction layer) also sounds promising but would require the deepest Winsock/POSIX socket programming knowledge\, and is surely beyond my talents. As you note\, it also doesn't fix code that tests against Winsock error codes.

- The third solution (dropping all E*/WSA* mappings) would again break all the code that tests against E* constants.

I will try to find time to digest these proposals properly\, and will certainly draw them to the attention of all relevant parties in deciding what to do about all of this.

Note well that solution 3 can equally well serve as a stepping stone to solution 2: once the interface is well-defined\, building such a wrapper becomes a SMOP for someone with the knowledge to do so. In fact it seems to me that *any* reasonable attempt at this implies executing solution 3 first. Note lastly that Marc’s attempt to handle all the details within AnyEvent is essentially congruent with solution 2.

Now\, about managing the transition:

One thing that occurs to me is that fixing what gets put in $! in and putting the WSAE* codes in $^E seem to be entirely separable. So maybe the latter could be done first.

Ideally\, might it even be possible to write a compat module loadable on older perls that retrofits putting WSAE* into $^E? (Loading it on newer perls would just be a noöp.)

If so\, then users would have a clean option to fix their code to work on Windows: upon detecting that they are Windows\, they would just ignore $! entirely and look at $^E instead.

Meanwhile\, over in $! land\, the mapping would be put back in\, working exactly like it did before – at the Perl level at least. Because correct code would be ignoring $! anyway on Windows\, this makes no difference.

What to do for XS is a harder issue. It may be that XS code will just have to live with the fact that WSAEWOULDBLOCK is suddenly no longer being mapped to EWOULDBLOCK.

Is that feasible?

*If* that combination comes together\, then a long deprecation could be instated before removing the WSAE*-to-E* mapping entirely.

That way\, things that sort-of work now would keep sort-of working for quite a while yet\, so there is time to fix them\, and in the meantime\, new code can be written to truly properly work in such a way that it won’t break after the deprecation cycle concludes.

How’s that sound?

Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 9 years ago

From @steve-m-hay

On 28 March 2015 at 12:21\, Aristotle Pagaltzis \pagaltzis@gmx\.de wrote:

* Steve Hay \steve\.m\.hay@googlemail\.com [2015-03-25 04:25]:

- The second solution (creating a better abstraction layer) also sounds promising but would require the deepest Winsock/POSIX socket programming knowledge\, and is surely beyond my talents. As you note\, it also doesn't fix code that tests against Winsock error codes.

- The third solution (dropping all E*/WSA* mappings) would again break all the code that tests against E* constants.

I will try to find time to digest these proposals properly\, and will certainly draw them to the attention of all relevant parties in deciding what to do about all of this.

Note well that solution 3 can equally well serve as a stepping stone to solution 2: once the interface is well-defined\, building such a wrapper becomes a SMOP for someone with the knowledge to do so. In fact it seems to me that *any* reasonable attempt at this implies executing solution 3 first. Note lastly that Marc’s attempt to handle all the details within AnyEvent is essentially congruent with solution 2.

Now\, about managing the transition:

One thing that occurs to me is that fixing what gets put in $! in and putting the WSAE* codes in $^E seem to be entirely separable. So maybe the latter could be done first.

As I wrote in another email (http://www.nntp.perl.org/group/perl.perl5.porters/2015/03/msg227029.html)\, I think putting the WSAE* codes into $^E is the only way to provide a robust solution to all this\, and having done so there would be little point in tinkering with what goes into $! at all\, other than to remove it at some point after a suitably long deprecation period.

Ideally\, might it even be possible to write a compat module loadable on older perls that retrofits putting WSAE* into $^E? (Loading it on newer perls would just be a noöp.)

That would certainly make it easier for people to switch to using the new $^E error checking\, rather than checking $! on older perls and $^E from 5.24 (or whatever) onwards. New perls would be setting $^E directly after each Winsock function call\, but I don't think there's any way for a module to hook into the (win32/) core and do the same; I guess it would have to work by overriding built-ins like connect()\, select()\, accept() with versions that call the originals and then set up $^E from $! as best it can. But unless that can work reliably then users would probably be better off just sticking with the old $! checking for older perls\, otherwise the new module would just be introducing more madness into the equation!

If so\, then users would have a clean option to fix their code to work on Windows: upon detecting that they are Windows\, they would just ignore $! entirely and look at $^E instead.

Meanwhile\, over in $! land\, the mapping would be put back in\, working exactly like it did before – at the Perl level at least. Because correct code would be ignoring $! anyway on Windows\, this makes no difference.

I wouldn't envisage taking the mapping out in the first place (until after a long deprecation period). Just leave it as-is\, but encourage people to switch over to $^E\, with a helping hand from your suggested new module if possible.

What to do for XS is a harder issue. It may be that XS code will just have to live with the fact that WSAEWOULDBLOCK is suddenly no longer being mapped to EWOULDBLOCK.

Is that feasible?

*If* that combination comes together\, then a long deprecation could be instated before removing the WSAE*-to-E* mapping entirely.

That way\, things that sort-of work now would keep sort-of working for quite a while yet\, so there is time to fix them\, and in the meantime\, new code can be written to truly properly work in such a way that it won’t break after the deprecation cycle concludes.

How’s that sound?

Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 7 years ago

From @jkeenan

On Thu\, 24 Apr 2014 18:15:49 GMT\, chorny wrote:

This is a bug report for perl from alexchorny@gmail.com\, generated with the help of perlbug 1.40 running under perl 5.19.11.

----------------------------------------------------------------- [Please describe your issue here]

Tests of AnyEvent fail on Strawberry Perl 5.19.11. This error did not appear on 5.18.2 and earlier.

t/handle/01_readline.t: 1..8 ok 1 - A line was read correctly ok 2 ok 3 - initial lines were read correctly AnyEvent::Handle uncaught error: A non-blocking socket operation could not be completed immediately. at t/handle/01_readline.t line 76. # Looks like you planned 8 tests but ran 3. # Looks like your test exited with 140 just after 3.

This RT has been open for 2-1/2+ years. According to http://matrix.cpantesters.org/?dist=AnyEvent\, AnyEvent version 7.13 is PASSing steadily on mswin32\, including\, most recently\, this report from Chorny\, who originally opened this ticket:

http://www.cpantesters.org/cpan/report/3ddfe2f2-6bf4-1014-b95a-2450d4098b66

In addition\, there was a lot of discussion of other issues in the RT -- discussion not specific to AnyEvent and discussion not resolved.

How shall we proceed?

Thank you very much.

[Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=low --- Site configuration information for perl 5.19.11:

Configured by strawberry-perl at Tue Apr 22 08:42:15 2014.

Summary of my perl5 (revision 5 version 19 subversion 11) configuration:

Platform: osname=MSWin32\, osvers=6.2\, archname=MSWin32-x86-multi-thread-64int uname='Win32 strawberry-perl 5.19.11.1 #1 Tue Apr 22 08:40:30 2014 i386' config_args='undef' hint=recommended\, useposix=true\, d_sigaction=undef useithreads=define\, usemultiplicity=define use64bitint=define\, use64bitall=undef\, uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler: cc='gcc'\, ccflags =' -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fno-strict-aliasing -mms-bitfields'\, optimize='-s -O2'\, cppflags='-DWIN32' ccversion=''\, gccversion='4.8.2'\, gccosandvers='' intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=12345678 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12 ivtype='long long'\, ivsize=8\, nvtype='double'\, nvsize=8\, Off_t='long long'\, lseeksize=8 alignbytes=8\, prototype=define Linker and Libraries: ld='g++'\, ldflags ='-s -L"C:\strawberry1911\perl\lib\CORE" -L"C:\strawberry1911\c\lib"' libpth=C:\strawberry1911\c\lib C:\strawberry1911\c\i686-w64- mingw32\lib C:\strawberry1911\c\lib\gcc\i686-w64-mingw32\4.8.2 libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 libc=\, so=dll\, useshrplib=true\, libperl=libperl519.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs\, dlext=xs.dll\, d_dlsymun=undef\, ccdlflags=' ' cccdlflags=' '\, lddlflags='-mdll -s -L"C:\strawberry1911\perl\lib\CORE" -L"C:\strawberry1911\c\lib"'

--- @INC for perl 5.19.11: C:/strawberry1911/perl/site/lib C:/strawberry1911/perl/vendor/lib C:/strawberry1911/perl/lib .

--- Environment for perl 5.19.11: HOME (unset) LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=C:\Program Files\Far Manager\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\strawberry1911\c\bin;C:\strawberry1911\perl\site\bin;C:\strawberry1911\perl\bin PERL_BADLANG (unset) PERL_HASH_SEED=0x11111111 SHELL (unset)

-- James E Keenan (jkeenan@cpan.org)

p5pRT commented 7 years ago

From @xsawyerx

On Tue\, 06 Dec 2016 14:19:11 -0800\, jkeenan wrote:

On Thu\, 24 Apr 2014 18:15:49 GMT\, chorny wrote:

This is a bug report for perl from alexchorny@gmail.com\, generated with the help of perlbug 1.40 running under perl 5.19.11.

----------------------------------------------------------------- [Please describe your issue here]

Tests of AnyEvent fail on Strawberry Perl 5.19.11. This error did not appear on 5.18.2 and earlier.

t/handle/01_readline.t: 1..8 ok 1 - A line was read correctly ok 2 ok 3 - initial lines were read correctly AnyEvent::Handle uncaught error: A non-blocking socket operation could not be completed immediately. at t/handle/01_readline.t line 76. # Looks like you planned 8 tests but ran 3. # Looks like your test exited with 140 just after 3.

This RT has been open for 2-1/2+ years. According to http://matrix.cpantesters.org/?dist=AnyEvent\, AnyEvent version 7.13 is PASSing steadily on mswin32\, including\, most recently\, this report from Chorny\, who originally opened this ticket:

http://www.cpantesters.org/cpan/report/3ddfe2f2-6bf4-1014-b95a- 2450d4098b66

In addition\, there was a lot of discussion of other issues in the RT -- discussion not specific to AnyEvent and discussion not resolved.

How shall we proceed?

I think we should resolve this issue and start either a thread or a ticket to continue this discussion. The breakage doesn't exist any longer (considering the test reports)\, but the greater issue of how to handle these codes (not expressed in the topic of this RT ticket) has yet to be determined.

p5pRT commented 7 years ago

From @jkeenan

On Tue\, 27 Dec 2016 11:11:47 GMT\, xsawyerx@cpan.org wrote:

On Tue\, 06 Dec 2016 14:19:11 -0800\, jkeenan wrote:

On Thu\, 24 Apr 2014 18:15:49 GMT\, chorny wrote:

This is a bug report for perl from alexchorny@gmail.com\, generated with the help of perlbug 1.40 running under perl 5.19.11.

----------------------------------------------------------------- [Please describe your issue here]

Tests of AnyEvent fail on Strawberry Perl 5.19.11. This error did not appear on 5.18.2 and earlier.

t/handle/01_readline.t: 1..8 ok 1 - A line was read correctly ok 2 ok 3 - initial lines were read correctly AnyEvent::Handle uncaught error: A non-blocking socket operation could not be completed immediately. at t/handle/01_readline.t line 76. # Looks like you planned 8 tests but ran 3. # Looks like your test exited with 140 just after 3.

This RT has been open for 2-1/2+ years. According to http://matrix.cpantesters.org/?dist=AnyEvent\, AnyEvent version 7.13 is PASSing steadily on mswin32\, including\, most recently\, this report from Chorny\, who originally opened this ticket:

http://www.cpantesters.org/cpan/report/3ddfe2f2-6bf4-1014-b95a- 2450d4098b66

In addition\, there was a lot of discussion of other issues in the RT -- discussion not specific to AnyEvent and discussion not resolved.

How shall we proceed?

I think we should resolve this issue and start either a thread or a ticket to continue this discussion. The breakage doesn't exist any longer (considering the test reports)\, but the greater issue of how to handle these codes (not expressed in the topic of this RT ticket) has yet to be determined.

Accordingly\, I'm resolving the ticket. Steve\, Aristotle\, bulk88\, others with an opinion -- please feel free to post on the mailing list something to start the discussion off. (I'd suggest not filing a new perlbug until we have something more specific that needs RT tracking.)

Thank you very much.

-- James E Keenan (jkeenan@cpan.org)

p5pRT commented 7 years ago

@jkeenan - Status changed from 'open' to 'resolved'