UdpSocket: packet content truncated when using a `Vec` as read buffer

[sunkit02]

I tried this code:

use std::net::UdpSocket;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let send_addr = "127.0.0.1:8080";
    let recv_addr = "127.0.0.1:8081";

    let send_socket = UdpSocket::bind(send_addr)?;
    let recv_socket = UdpSocket::bind(recv_addr)?;

    let msg = String::from("Hello, world!");
    let amt_sent = send_socket.send_to(msg.as_bytes(), recv_addr)?;

    // Swap the following two lines to see the change
    // let mut buf = [0; 1024]; // This works
    let mut buf = Vec::with_capacity(1024); // This doesn't

    let (amt_recv, _) = recv_socket.recv_from(&mut buf)?;

    println!(
        "Buffer content: {}",
        String::from_utf8(buf[..amt_recv].to_vec())?
    );

    // This fails when using a `Vec` as buf instead of a fixed size array
    assert_eq!(amt_sent, amt_recv);

    Ok(())
}

I expected to see this happen: The assertion assert_eq!(amt_sent, amt_recv) should pass and the stdout has the following output:

Buffer content: Hello, world!

Instead, this happened:

The assertion failed with the following output:

assertion `left == right` failed 
 left: 13
 right: 0

and the stdout is as following:

Buffer content:

I am running Arch Linux and here is the output of uname -a:

Linux Archbox 6.6.22-1-lts #1 SMP PREEMPT_DYNAMIC Sat, 16 Mar 2024 06:20:33 +0000 x86_64 GNU/Linux

Meta

rustc --version --verbose:

rustc 1.76.0 (07dca489a 2024-02-04)
binary: rustc
commit-hash: 07dca489ac2d933c78d3c5158e3f43beefeb02ce
commit-date: 2024-02-04
host: x86_64-unknown-linux-gnu
release: 1.76.0
LLVM version: 17.0.6

Backtrace

There is no backtrace since the program compiled successfully and didn't crash.

Edit: Correct let mut buf = Vec::new() to let mut buf = Vec::with_capacity(1024) in the code I tried.

[the8472]

This is normal. UDP sockets are packet-oriented which means you get 1 chance to write one into a buffer per read/recv syscall (if you're not using MSG_PEEK), which means you need to supply a sufficiently sized buffer. If you don't it gets truncated.

This is documented in

• https://man7.org/linux/man-pages/man7/udp.7.html
• https://man7.org/linux/man-pages/man2/recvmsg.2.html

or the equivalent socket API documentation of your target platform.

[sunkit02]

My apologies, I initially came across the issue when creating the vector using Vec::with_capacity(1024) but I forgot to change it back after experimenting with some other options. Does that make any difference?

[sunkit02]

I got the code to work after initializing buf with vec![0; 1024]. @the8472, you are right that the issue here is the lack of sufficient space to read the packet into, thank you so much for your help. I totally overlooked the fact that Vec::new only creates a dangling pointer.

However, Vec::with_capacity while not actually initializing the memory allocated, does allocate the specified memory and can be written to right after the allocation without being zeroed out or otherwise initialized if I'm not mistaken. So I am wondering if the behavior of truncating the packet when the buffer is in fact allocated the desired behavior in this scenario?

[tbu-]

It is the expected behaviour. recv_from takes a &mut [u8] and passing an empty vector that has a capacity will pass the empty slice. &mut buf will get turned into the empty &mut [] slice.

[sunkit02]

I see. That makes sense. Thank you so much for the explanation @tbu-