Socket module bug on OpenVMS
exarkun at divmod.com
Sun Oct 22 19:18:13 CEST 2006
On Sun, 22 Oct 2006 19:00:22 +0200, Irmen de Jong <irmen.nospam at xs4all.nl> wrote:
>Recently I was bitten by an apparent bug in the BSD socket layer
>on Open VMS. Specifically, it appears that VMS defines MSG_WAITALL
>in socket.h but does not implement it (it is not in the documentation).
>And I use the socket.MSG_WAITALL flag on my recv() calls... and
>then they crash on OpenVMS.
>I don't have access to an OpenVMS machine myself so could someone
>else that has (or has more knowledge of it) shed some light on it?
>This also raises the question to what extent Python itself should
>work around platform specific "peculiarities", such as this one.
>There's another problem with socket code on Windows and VMS systems,
>where you get strange exceptions when using a "too big" recv() buffer.
>Things like this force me into writing all sorts of error checking
>code or platform specific functions, to work around these bugs.
>Just for what was supposed to be a simple socket recv() and a
>simple socket send()...
>In my opinion Python's socket module itself could implement these
>workarounds. That would make user code a lot cleaner and less
>error prone, and more portable. What do other people think?
I think everyone can agree that Python shouldn't crash. It sounds like
the MSG_WAITALL check could be made somewhat more paranoid to detect the
behavior exhibited by OpenVMS. Of course, in practice, this is weighed
against developer time and relevative popularity of various platforms.
How many people are using Python on OpenVMS?
Whether Python should propagate other kinds of errors from the underlying
platform is a harder question though. At the lowest level interface, it
seems to me that it _should_ propagate them. If there is a general way to
handle them, then a higher layer can be built on top of that lowest level
which does so. Applications which are not interested in dealing with these
errors can use the higher-level interface (and it probably even makes sense
to recommend the high-level interface for most applications). Python doesn't
always do a good job of keeping the high and low levels separate though, and
this seems like an area in which Python could stand some improvement.
More information about the Python-list