Re: Linux recvfrom() broken (was: DNS problems)

Alan Cox (alan@lxorguk.ukuu.org.uk)
Tue, 18 Aug 1998 23:41:54 +0100 (BST)

> the manpage entry for solaris 2.5.1 is identical except it refers to
> socket(3N) instead of socket(2).
>
> recvfrom() returns the number of octets in the message, it does not
> over-run the buffer supplied, but discards any octets that do not fit into
> the buffer. In this way you know you know the reply over-ran the buffer
> you supplied and you can do something about it.

Linux 2.0 returns the number of bytes removed from the queue not the
number copied. It doesn't overrun the buffer.

---




Draft 6.4 of the POSIX 1003.1g spec says


"The amount of data requested by a recv() or recvfrom() call is indicated
 by the len parameter"


"The function shall return as much data as possible from the first
segment of the queue"


"The amount of data returned shall be the smaller of the data available
in the segment or the amount requested."


"Upon successful completion the functions return the number of octets
 received"


Unfortunately it does not say if the 'number of octets received' is the
number copied or the number removed from the queue. 2.0 interprets it
as the number removed from the queue. Im not sure what 2.1 does - I would
assume nobody gratuitiously changed the API.


The only way to answer this one is for someone wiht the right links to
refer the question to the POSIX 1003.1g committee for clarification. I
could certainly build a convincing case for either side here.


Ok so who has 1003.1g connections ?




Alan




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html