Socket module bug on OpenVMS
Jean-François Piéronne
jf.pieronne at laposte.net
Sun Oct 22 13:57:54 EDT 2006
> Hi,
>
> 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.
>
Which Python version, OpenVMS version, IP stack and stack version?
If you think this is a Python on OpenVMS problem, send me a small
reproduced anf I will take a look.
If you think it's a OpenVMS problem and if you can provide a simple
reproducer and have a support contract I suggest you call HP, but I
suspect that if it's not documented the reply would be not (yet?) supported.
> 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?
>
>
It appear that the only place, in the Python source code, where
MSG_WAITALL is used is in socketmodule.c:
#ifdef MSG_WAITALL
PyModule_AddIntConstant(m, "MSG_WAITALL", MSG_WAITALL);
#endif
May be a workaround is to not use MSG_WAITALL (currently) on OpenVMS and
in next version I will not defined MSG_WAITALL in the socket module on
OpenVMS.
If you need an access to an OpenVMS let me know.
>
> 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.
>
Old Python version on OpenVMS have bugs in the socket module which have
been fixed in newer version. Be sure to check using the latest kit.
> 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?
>
>
> Regards
> --Irmen de Jong
Jean-Francois Pieronne
More information about the Python-list
mailing list