develooper Front page | perl.perl5.porters | Postings from March 2016

Re: Putting Winsock errors into $^E

Thread Previous | Thread Next
March 23, 2016 23:11
Re: Putting Winsock errors into $^E
Message ID:
On Wed, Mar 16, 2016 at 10:17 PM, Aristotle Pagaltzis <>

> * Laurent <> [2016-03-17 00:00]:
> > I disagree with your argument that because the code "works" (to some
> > extend) then it is not broken. Perl, for instance, has been broken for
> > this reason for years (assigning WSA* codes to E* constants), but
> > "worked fine"... until the namespace clash happened. And your solution
> > is still broken as it puts a WSA error into $! with a POSIX code.
> The code has always been broken because Perl forced it to be broken. But
> it worked as well as circumstances allowed. To suddenly now make it stop
> working at all and force it to be updated to be correct to work again is
> abusive. Perl forced the code to be broken so it has the responsibility
> in this relationship to make the broken code work as well as it can, and
> to offer the *option* for new or updated code to be correct, and then to
> wait for old code to catch up.

Still... mixing semantically incompatible Posix constant/values with
WinSock values/constants is quite a major issue, and the current Perl is
not fixing it.
IMO, the main reason why there is potentially a lot of broken code out
there is because most of the winsock errors are semantically close (and
possibly even compatible) with their Posix counterparts in a number a
real-life situations. So most broken code happened to work, and is probably
"not-so-broken" and there is possibly something to be done about it.

Translating WSAEWOULDBLOCK to EWOULDBLOCK for a number is winsock calls (eg
send/recv) is probably fine, and that may cover a wide part of the
not-so-broken code.
But continuing to translate WSAEWOULDBLOCK to EWOULDBLOCK for winsock
connect() is really completely broken and is potentially the main reason
why broken code is broken and needs to be fixed. I can't believe one can
accept to break working code on one side and make such plainly broken code
work on the other side.
At least, winsock connect should return EINPROGRESS in $! in this case...
And that's a start for more semantically correct translation from WSAE*
errors to E* ones, depending on the calls...

In addition, if WSAE* error is unknown in the Posix space, $! should rather
be set to some E* error covering this (eg: WSAESHUTDOWN => EPIPE), or be
set to newly locally defined Posix value (eg: WSAESOCKTNOSUPPORT =>
ESOCKTNOSUPPORT). But letting $! comparison with WSA constants or values
(or $^E with E* constants) happen to work, could be avoided.

Finally, now that $^E holds the winsock error, convert_errno_to_wsa_error()
could disappear... it is hard enough to convert a WSAE* error to a E*
depending on the context, it is certainly impossible to reverse it out of
context. Why one would do that anyway, now that $^E still holds the correct


-- Laurent

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About