Re: [RFE] function to read a file descriptor

[Debarshi Ray]

> What's the use-case of this function? You said that you want to "safely"
> read from sockfd, but can you explain what you mean by that?

I am actually reading from a PF_NETLINK socket and want the entire
data, which can be spread over multiple consecutive messages, in a
buffer. Now the BUFSIZ documentation says its "value is guaranteed to
be at least `256'". Now one of the multipart messages to get the
entire routing table from the Linux kernel is 504 bytes long on my
GNU/Linux system.

Using read-file might not always be possbile since we would lose the
'flags' argument of 'recv'.

> I don't see the point in performing the loop here, since
>  - for SOCK_DGRAM sockets (e.g. UDP) the parts of the first message that
>    don't fit in BUFSIZ bytes will be discarded; performing more recv()
>    calls afterwards will not recover them, but will read a different packet
>    each,

Isn't it possible that multiple packets are available? It might be the
case with PF_NETLINK sockets and multipart messages.

>  - for SOCK_STREAM sockets (e.g. TCP) your function is reading all that is
>    currently available. What's the point? Why not return a block of BUFSIZ
>    bytes to the caller, then in the next call another block of BUFSIZ bytes
>    and so on? BUFSIZ is large enough that this should hardly have a measurable
>    effect on speed.

True, but there are instances where having the entire data in a buffer
makes it easier to parse it. eg., the routing table example.

I am not sure if this is a common enough use-case to warrant an entry in Gnulib.

Happy hacking,
Debarshi