[issue13045] socket.getsockopt may require custom buffer contents

[Charles-François Natali]

Charles-François Natali <neologix at free.fr> added the comment:

> I've attached an update for the previous patch. Now there's no more
> overloading for the third argument and socket.getsockopt accepts one more
> optional argument -- a buffer to use as an input to kernel.

Remarks:
"""
+   length.  If *buffer* is absent and *buflen* is an integer, then *buflen*
[...]
+   this buffer is returned as a bytes object.  If *buflen* is absent,
an integer
"""
There's a problem here, the first buflen part should probably be removed.

Also, you might want to specify that if a custom buffer is provided,
the length argument will be ignored.

> By the way, I don't really think that any POSIX-compliant UNIX out there
> would treat the buffer given to getsockopt in any way different from what
> Linux does. It is very easy to copy the buffer from user to kernel and back,
> and it is so inconvenient to prevent kernel from reading it prior to
> modification, that I bet no one has ever bothered to do this.

Me neither, I don't expect the syscall to return EINVAL: the goal is
just to test the correct passing of the input buffer, and the length
computation.

If we can't test this easily within test_socket, it's ok, I guess the
following should be enough:
- try supplying a non-buffer argument as fourth parameter (e.g. and
int), and check that you get a ValueError
- supply a buffer with a size == sizeof(int) (SIZEOF_INT is defined in
Lib/test/test_socket.py), and call getsockopt(socket.SOL_SOCKET,
socket.SO_REUSEADDR, 0, <buffer>): this should normally succeed, and
return a buffer (check the return type)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13045>
_______________________________________