> 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
