Repository navigation
Bound reference lifetimes sourced from pointer parameters - #697
Merged
Merged
Conversation
cpu
approved these changes
Oct 25, 2026
cpu
left a comment
Member
There was a problem hiding this comment.
Thanks! This looks good to me.
I tacked on two commits at the end to try and get some targetted regression coverage. Those two commits applied to main without the rest of the rework fail in CI as expected.
Feel free to drop/rework them if you have opinions.
Member
|
#699 should fix the macOS CI failure. |
ctz
force-pushed
the
jbp-lifetimes
branch
4 times, most recently
from
October 26, 2026 16:18
f4556ca to
eaba94b
Compare
cpu
approved these changes
Oct 26, 2026
cpu
left a comment
Member
There was a problem hiding this comment.
documentation / Generate API documentation (pull_request) - Failing after 1m
I think you need to run the docgen too (sorry, lots of manual steps in this repo).
This created a `&'static CStr` from a function parameter, retaining the caller's memory. Copy it instead.
Functions like `slice::from_raw_parts` and `CStr::from_ptr` infer the lifetime of the resulting reference. This makes it easy to take a pointer argument and end up with a `'static` reference, which is not a common interpretation of a C API. Instead, take the pointer itself by reference to its local, and then transfer that lifetime to the result. This means the lifetimes created by `try_ref_from_ptr!`, `try_mut_from_ptr!`, `try_slice!`, `try_slice_mut!` and the new `try_cstr!` are bound to the local. This exposes two places that relied on an inferred `'static`: `Hpke::grease_public_key`, whose suites really are `'static`; and `rustls_accepted_alpn`, which has preexisting documentation explaining this and cannot express a better lifetime.
Help verify our claim that the server_name is copied by the rustls-ffi internals by freeing it explicitly after `rustls_client_connection_new()`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The goal of this PR is to arrange that the compiler complains about GHSA-rc3f-4j82-cmrg in a useful way, and then spread that pattern as far as possible.
With reordering the commits in this PR, this is achieved: