-
Notifications
You must be signed in to change notification settings - Fork 666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
recvmsg
should take &mut [u8]
instead of &mut Vec<u8>
for cmsg_buffer
#2523
Comments
erenon
pushed a commit
to erenon/nix
that referenced
this issue
Oct 22, 2024
Instead of a Vec, to avoid forcing an allocation. `cmsg_space!` now creates a zero initialized vec (instead of a zero-len vec with capacity): this way callsites do not need to be changed. Fixes nix-rust#2523
Possible fix prepared: #2524 |
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 22, 2024
Instead of a Vec, to avoid forcing an allocation. `cmsg_space!` now creates a zero initialized vec (instead of a zero-len vec with capacity): this way callsites do not need to be changed. Fixes #2523 Co-authored-by: Benedek Thaler <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently,
recvmsg
takes amut cmsg_buffer: Option<&'a mut Vec<u8>>
argument. This potentially forces the caller to allocate a right-sized Vec (or keep one around), thoughrecvmsg
implementation immediately produces a slice of the vector, and never uses it as a vector.What's the reason for having Vec on the interface? Could we have a
&mut [u8]
instead? That'd allow the called to put the buffer onto the stack.The text was updated successfully, but these errors were encountered: