为何recvmsg不支持MSG_CTRUNC标志？关于辅助数据长度的问询

Great question! Let's break this down by first recalling how MSG_TRUNC and MSG_CTRUNC work, then diving into the design choices behind this asymmetry.

First, a quick recap from the man 2 recv docs:

• MSG_TRUNC can be passed as a flag to recvmsg, and when set, the call returns the full length of the message even if your buffer was too small (instead of just the number of bytes copied). It also gets returned in the msg_flags field if the regular data was truncated.
• MSG_CTRUNC only appears in the msg_flags field after the call, indicating that your auxiliary (control) data buffer was too small and some control messages were truncated. You can't pass it as an input flag to get the real length of the auxiliary data.

So why this difference? Here are the key reasons:

1. The structural complexity of auxiliary data #

Regular data is a single, contiguous block—calculating its full length is straightforward for the kernel (it just checks the size of the pending message in the socket buffer).

Auxiliary data, though, is a linked list of cmsghdr structures, each with its own length and payload. To get the total length of all control messages, the kernel would have to iterate through every cmsghdr in the pending message, sum up CMSG_SPACE(len) for each, and return that total. This is more computationally expensive than checking a single length value for regular data.

Early socket API designers likely prioritized simplicity for the common case (regular data) and decided that the added complexity of supporting MSG_CTRUNC as an input flag wasn't worth it, especially since truncated auxiliary data is a less frequent scenario.

2. Historical design priorities #

When recvmsg was introduced, the primary use case was handling regular data transfers. Auxiliary data (like credentials, file descriptors, or IPv6 options) was an added feature, not the main focus. The MSG_TRUNC flag was built for the common case where applications need to know how big a buffer to allocate for the next message.

For auxiliary data, the assumption was that applications either:

• Know exactly what control messages they expect (and can size the buffer accordingly), or
• Can handle truncation by checking MSG_CTRUNC in the return flags and reallocating a larger buffer to try again.

3. Lack of a clear, consistent way to return the length #

If MSG_CTRUNC were accepted as an input flag, how would the kernel return the total length of auxiliary data? For regular data, the return value of recvmsg gives the full length when MSG_TRUNC is set. But auxiliary data's total length would need a separate field in the msghdr structure, which would require changing the API—something that's avoided in stable system APIs to maintain backward compatibility.

There's no existing field in msghdr that could carry this length without breaking existing code, so adding support for MSG_CTRUNC as an input flag would require more than just kernel changes; it would need API modifications that aren't feasible for a long-standing system call like recvmsg.

Workaround for getting auxiliary data length #

If you really need to know the full length of auxiliary data before allocating a buffer, your best bet is to:

• Call recvmsg with a small control buffer (even zero-length)
• Check if MSG_CTRUNC is set in msg_flags
• If it is, increase the size of your control buffer and try again, repeating until MSG_CTRUNC is no longer set.

This is a bit clunky, but it's the standard way to handle this scenario given the current API constraints.

内容的提问来源于stack exchange，提问作者user3076936