Re: recvmsg_realloc

[christos%astron.com@localhost (Christos Zoulas)]

In article <9925602d-ba77-ab23-106d-35a799b8ab45%marples.name@localhost>,
Roy Marples  <roy%marples.name@localhost> 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