In article <9925602d-ba77-ab23-106d-35a799b8a...@marples.name>, Roy Marples <r...@marples.name> wrote: >Hi List > >I use recvmsg(2) a fair bit in code. >However, a lot of the time I can't be certain how large a buffer I would >need, so they all ship with a handy function called recvmsg_realloc, >which as you can guess, will realloc the last iovec so that the whole >message fits. Think of it as a convenience function akin to getline(3). > >OK, it's not just my code. For BSD, a fair few progs read from the >routing socket with a fixed 2048 char buffer. >While this should be plently, due to the use of read(2) it could >overflow if the system is sending more than the program can process. > >Looking over the tree, the following progs should be re-coded to use >recvmsg rather than their current (and potentially buggy how I >understand it) read(2) implementation, and thus benefit from >recvmsg_realloc: >wpa_supplicant >route >ifwatchd >rtadvd >dhcpcd > >I'd like to add this to libc instead of bolting it on for this and >possibly more applications. Or just recode the above with a fixed width >buffer and use recvmsg, keeping this out of libc. > >Comments welcome, protoype below.
Are you planning to change our kernel so that it handles MSG_TRUNC like linux does (return the actual length of the buffer instead of ignoring the flag)? How about handling MSG_CTRUNC too? christos
