-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Add types for inspecting control messages in Unix socket ancillary data #117196
Conversation
r? @cuviper (rustbot has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
15d4daf
to
f50a22f
Compare
@rustbot label +T-libs-api -T-libs |
r? libs-api |
This comment has been minimized.
This comment has been minimized.
f50a22f
to
bd2eea0
Compare
Reassigning to Josh, who has opinions about the existing ancillary data API and the proposed one. r? joshtriplett |
1cdcf8a
to
fc50372
Compare
CI is green now (having done its job of reminding me that UI tests exist...) |
fc50372
to
d160774
Compare
d160774
to
10f6389
Compare
Note: the most recent iteration of the RFC doesn't require |
r? libs-api |
Tracking issue: #76915
RFC for
unix_socket_ancillary_data
redesign: rust-lang/rfcs#3430The portion of the new API dealing with control message inspection seems to be non-contentious, so this PR implements it. The types and logic are all separate from the current implementation, so they can co-exist without worries about compatibility or unexpected behavior changes.
New types:
ControlMessage<'a>
is a borrowed reference to a single control message. No inspection of the message content, just the generic metadata (cmsg_level
,cmsg_type
) and data slice.&ControlMessages
is a wrapper around&[u8]
that has aniter() -> ControlMessagesIter
method.ControlMessagesIter<'a>
iterates over control messages by inspectingcmsg_len
Includes docs and tests.