Message144958
> 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) |
|
Date |
User |
Action |
Args |
2011-10-05 16:45:32 | neologix | set | recipients:
+ neologix, pitrou, python-dev, ximaera |
2011-10-05 16:45:31 | neologix | link | issue13045 messages |
2011-10-05 16:45:31 | neologix | create | |
|