Charles-François Natali <neolo...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue13045> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
