# Libs-API Meeting 2026-04-21

###### tags: `Libs Meetings` `Minutes`

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Nia, Mark, The 8472, Josh, Amanieu, Folkert, Nurzhan

## Agenda

- Triage
- Anything else?

### Security meeting

Josh: We had some of the Foundation security folks who got access to the Mythos preview. They started looking at security of std and looking for soundness issues or bugs. They're expecting to have a non-trivial number of those. They want to talk to us about handling that, the mechanisms of that. I worked with Nia to invite Walter from security and three of the people from security response team to chat with us in the second hour of this meeting. They will demo some examples of what they've found. This is to give us a flavor of the things that we'll be dealing with. We need to talk about that and figure out how to deal with the oncoming wave. They might or might not be security issues. For the second hour of the meeting, we could close the meeting to Libs, Libs API and security (+ program managers and Nia). This means separate private minutes.

Nia: I've set up a separate Hackmd for that. Not sure how to handle permissions because...

Josh: I've been thinking of making a temp hackmd. Can you only allow a team to have permissions?

Nia: No. I'll DM the link on Zulip.

## Triage

### FCPs

23 rust-lang/rust T-libs-api FCPs

- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/116258 *Tracking Issue for explicit\-endian String::from\_utf16* - (1 checkboxes left)
- merge rust.tf/98407 *Tracking Issue for \`SyncView\`* - (0 checkboxes left)
- merge rust.tf/140808 *Implement Default for &Option* - (1 checkboxes left)
- merge rust.tf/141994 *add Iterator::contains* - (1 checkboxes left)
- merge rust.tf/76314 *Tracking Issue for atomic\_from\_mut* - (1 checkboxes left)
- merge rust.tf/151379 *Stabilize \`VecDeque::truncate\_front\`* - (3 checkboxes left)
- merge rust.tf/149926 *Do not deduplicate captured args while expanding \`format\_args!\`* - (1 checkboxes left)
- merge rust.tf/111688 *Tracking Issue for ExitCodeExt on Windows* - (3 checkboxes left)
- merge rust.tf/109737 *Tracking Issue for \`once\_cell\_try\`* - (3 checkboxes left)
- merge rust.tf/121641 *Tracking Issue for \`OnceCell/Lock::get\_mut\_or\_init\`* - (3 checkboxes left)
- merge rust.tf/134021 *Implement \`IntoIterator\` for \`\[&\[mut\]\] Box\<\[T; N\], A\>\`* - (3 checkboxes left)
- merge rust.tf/153261 *Partially stabilize \`ptr\_alignment\_type\` as \`alignment\_type\`* - (3 checkboxes left)
- merge rust.tf/142748 *Tracking Issue for producing a \`Result\<(), E\>\` from a \`bool\`* - (3 checkboxes left)
- merge rust.tf/138215 *Tracking Issue for integer formatting into a fixed\-size buffer* - (3 checkboxes left)
- merge rust.tf/153990 *Decide and document where stdarch intrinsics are allowed to diverge from asm behavior* - (4 checkboxes left)
- merge rust.tf/126769 *Tracking Issue for \`substr\_range\` and related methods* - (3 checkboxes left)
- merge rust.tf/136327 *Tracking Issue for \`unsafe\_cell\_access\`* - (4 checkboxes left)
- merge rust.tf/149219 *Allow shortening lifetime in CoerceUnsized for &mut* - (4 checkboxes left)
- merge rust.tf/127544 *Tracking issue for CommandExt::show\_window* - (3 checkboxes left)
- merge rust.tf/155113 *Ensure Send/Sync impl for std::process::CommandArgs* - (3 checkboxes left)
- merge rust.tf/155153 *Ensure Send/Sync is not implemented for std::env::Vars{,Os}* - (3 checkboxes left)

[joshtriplett (13)](https://rfcbot.rs/fcp/joshtriplett), [scottmcm (1)](https://rfcbot.rs/fcp/scottmcm), [BoxyUwU (1)](https://rfcbot.rs/fcp/BoxyUwU), [spastorino (1)](https://rfcbot.rs/fcp/spastorino), [nikomatsakis (1)](https://rfcbot.rs/fcp/nikomatsakis), [dtolnay (3)](https://rfcbot.rs/fcp/dtolnay), [lcnr (1)](https://rfcbot.rs/fcp/lcnr), [BurntSushi (15)](https://rfcbot.rs/fcp/BurntSushi), [oli-obk (1)](https://rfcbot.rs/fcp/oli-obk), [Amanieu (3)](https://rfcbot.rs/fcp/Amanieu), [the8472 (16)](https://rfcbot.rs/fcp/the8472)

### (nominated) rust.tf/44930 *Tracking issue for RFC 2137: Support defining C\-compatible variadic functions in Rust (c\_variadic)*

Nia: Very old, got nominated by Folkert.

Folkert: This is old, so a bit of a checkin. The original design adopted the C names, we were wondering if we should stick to them (familiar) or use more Rusty names. Not sure how familiar everyone is with the C api. We have ??, which you can clone and dispose of. This is unsafe and target-specific. You can do va_copy, va_end and va_arg that you can do. Over the past couple of months, we changed va_copy to a Clone impl, and va_end to a Drop impl. We want to communicate the idea of status changed and ??. VaArcSafe... was the name we liked.

1) Sanity check: are we impl that trait for the right types, or should there be smth else? Maybe it doesn't make sense for references, ??, because those types have additional safety requirements, so maybe would be better to let users deal with that themselves. 128 integers we might want to keep out of stabilization.

2) Where should this live? Currently: core::ffi, maybe we want to give it its own module publicly.

Josh: 1) The summary in the linked issue, the arg fn looks like it should return T (folkert: yeah, will fix). Other than that, looks right. 2) This isn't just var arg mechanism -- it's C-compatible var arg mechanism. Whenever we have this, we try to use a C-reminiscent name for a C-compatible concept. In this case, calling it va_list is important because it's specific to that instead of a generic vararg mechanism. This fn is unsafe, doesn't tell you when it's done, doesn't return Option. If you ask for too many or not enough things, bad things happen. Therefore, invoking Iterator feels like the wrong metaphor. We should call it Arg, or next_arg or something.

T8: We have an internal method called next_unchecked that could fit in. We use it for trusted iterator where the number of elements is certain. Are the trait impls portable? Do all the platforms support the same set of types?

Folkert: No. It depends. It's cursed because it's compatible with C. We impld it for c_int, which ??. For AVR we had to figure out ??.

T8: ?? lists only std types, that's why I'm wondering.

Folkert: The FFI types are aliases. The impls you see depend on the target the docs were built for.

T8: What would happen if impl VarArgSafe for for the ffi aliases instead of the primitives.

Folkert: We thought of that, but there may be gaps. You don't want to impl ?? for ?? that's bigger. In any case, the Cint and Clong are just aliases. I talked about them to show the connection to C.

T8: I wonder how rustdoc handles it when ... alias. It might be clearer to the user that it's platform-specific.

Folkert: ?? I think the current arg is as unchecked as it can be. So it should live in the ... but could cause more UB.

T8: I was just saying that we could call it next_unchecked.

Josh: Context: The cursedness goes beyond C compat. C was cursed because of compat with assembly. You can't pass a u8 via varargs because it's been passed in smth register-sized, though on some platforms may be passed via stack. Can only support u32/u64 because it's the machine word size. I agree with T8 that we should document this, and we can't rely on rustdoc for that because of aliases. Would be good to generate ?? in the doc comments saying it's expected to be implemented for such and such integer sizes, but it would depend on your target.

Nia: On the naming question, I'm convinced by the `next_unchecked` argument. `next_arg` is also fine, but `arg` doesn't convey change of state.

Josh: Agreed. Having next in the name makes sense. Should we mark the method unsafe, or should we call it next_arg and rely on the unsafety to tell people it's unsafe?

Amanieu: Preference for next_arg. next_unchecked doesn't make as much sense because there's no safe version.

Josh: Chaining next_arg calls feels right.

T8: It's not null-terminated?

Josh: No. Depends? I was not kidding when I said radioactive unsafe.

T8: This will only be relevant for C and nobody is supposed to use this in Rust-Rust code?

Josh: Yes. Theoretically, someone could, but even then almost any interface would be better unless you're trying a varargs-related design

T8: Then the C-like name is fine.

Josh: Rust variable arguments will look completely different than this and be safer.

Amanieu: Other questions? Specifically on supporting more types, my intuition is that this trait should be implemented only for the types the platform ??

T8: MaybeUninit?

Amanieu: No because ?? needs to be initialized.

T8: Can't you have a hole in the list?

Nia: No.

Amanieu: For the same reason, `NonZero*` shouldn't be implementors. They're not C types.

T8: ...If someone writes a u8 in a register and then passes that?

Amanieu: If you're passing a u8 as an argument, you expect to fetch u8 on the other side.

T8: But that's not vararg-safe

Amanieu: C promotes the u8 to a u32, we require doing promotion manually because we don't have integer promotion. If you pass i32 and expect i64, that's UB.

Folkert: If you have a union in C, whether that's initialized is unclear.

Amanieu: Who knows.

Folkert: Happy to keep them out for now.

Josh: I agree that we shouldn't support char, NonZero and NonNull. OTOH, I'd love to be able to pull something as an `Option<NonNull<>>`. Then we have conversions.

Amanieu: We should strictly say "this must match the type that was given as the input exactly".

Nia: We want what Josh wants in the Rusty way of doing this.

Josh: Ok, so we only support the C-compat types, and then let users build around that.

Nia: Yes, we're not making it impossible for user code to provide this.

Josh: On placing/modules, if this has 12 types and different functions, I'd be tempted to put it in its own module. But now it's a type and method, which makes me want to put it into ffi.

Amanieu: And a trait.

Josh: It's unclear if it's going to be pub.

Folkert: It's pub but sealed.

Folkert: Trevor proposed a separate module for docs purposes, but having it in ffi is fine.

Nia: I'd expect most of the documentation on the struct.

Josh: VaList would have the general "this is the C variable argument (varargs) mechanism, here's information on that", while VaArgSafe would be for the cursed details of target-specific types and promotion.

Folkert: If anyone has thoughts on how to support 128 types, I'd be all ears.

Amanieu: My view is that the set of supported types is platform-specific.

Folkert: Then we want a set of platforms on which this is FFI-safe.

Amanieu: I don't think the list of targets where ?? is FFI-safe is ??. It should be, but it isn't.

Amanieu: There's also the issue that BitInt(128) is not the same as uint128_t.

Josh: If there's a 128-bit type on the platform that's distinct from bit128, we should map to that. ??

T8: That's going to be an interesting documentation.

Folkert: Yeah, it's terrible. I don't even know how to figure it out. Do I just ?? a hundred targets?

Amanieu: ?? usually has a platform ABI descibing the calling convention.

Nia: We could incrementally build a list of targets, no need to build it in one go.

Josh: Agreed. You might look at libffi, the c library that implements building calls at runtime because it also needs to know how you use types on various platforms.

Amanieu: As a general rule, I believe gcc supports ?? on ?? but does on 32-bit targets.

Nia: Seems like everyone's ok with VaArgSafe as a name?

Amanieu: Not a huge fan, but can't come up with a better one.

Nia: next_arg for the method?

(OK.)

Nia: We agree that only primitives where all bit patterns are valid.

(Yes.)

Nia: Agreement to ship as is with the updated name for the method?

Amanieu: I strongly think we shouldn't support MaybeUninit because there's no C equivalent.

Folkert: union?

Amanieu: Then you should pass a union.

Folkert: It's fine, I haven't seen it come up.

Nia: So, for now we don't support vararg unions.

Josh: If a specific use case for it comes up, then we listen. Until that, we say YAGNI.

Nia: For u128, what's the solution?

Folkert: I think we agreed to add it on platforms where we're confident it works. I'll check some targets ?? tier 1 and go from there. I'll comment on the issue.

Josh: How close are we to stabilization FCP?

Folkert: Need to convince Ralf that we're good. A couple of targets where we'll panic. On some targets, we can't prove that the impl is correct, though we think it is.

Josh: So we're on the border line, and you'll ping us when it's ready for FCP. This is one of the biggest items on the question of whether there's a C interface that you can't write in Rust. So we're close to closing the gap of being able to express every C API in Rust.

### (nominated) rust.tf/152367 *Derives \`Copy\` for \`ffi::FromBytesUntilNulError\`*

Nia: This is the record for smallest change nominated (6 characters).

Josh: Seems fine.

Nia: We have to commit to Copy, but it seems fine.

Amanieu: It's returned from ??.

Josh: `FromBytesWithNulError` is a trivial enum where everything is `Copy`. `FromBytesUntilNulError` is even simpler because you can't point to where the NUL *isn't*.

Nia: I'll reply.

### (nominated) rust.tf/154374 *Rename \`MetaSized\` trait to \`SizeOfVal\`*

Nia: I say we let this cook for another week, and then put our foot down on naming.

T8: Did you post a summary to zulip?

Nia: I'll post it.

Josh: We should communicate that we don't think `SizeOfVal` is a good name and that we think `MetaSized` or `MetadataSized` is more informative.

### (nominated) rust.tf/154665 *add safety sections for three functions in core::mem*

Nia: This is just moving some docs...

Josh: Might be part of the project goal on safety docs, but looks like ??

(Mark left a comment for libs-api: https://github.com/rust-lang/rust/pull/154665/changes#r3105634625)

(...)

Nia: Better to plan for the future and say that this might turn into a compile error. Would people be okay with that?

Josh: Seems fine.

T8: In a previous debate on array length we settled on a runtime panic because we didn't want that kind of breaking change.

Nia: I guess we already make this guarantee, no? This is what it's doing right now. This makes the guarantee more explicit instead of keeping it an implementation detail. If we do, folks working on the new transmute might protest. Ok, in the PR, the old documentation states that it's not a compile-time error is Src and Dst have different sizes. So I changed my mind, we should only guarantee a panic.

T8: If we say it's UB and keep that, then the panic is just a safety rail.

Nia: Sure, but the PR is suggesting guaranteeing a panic. We already had the panic via an assert, just didn't guarantee. We would be guaranteeing not to change the assert into a `debug_assert` or similar.

(After the security meeting.)

### (nominated) rust.tf/154834 *Stabilize \`tcp\_deferaccept\`*

Josh: The upstream man page is patched. I sent a patch, and it got accepted.

Amanieu: We already replied.

(Unnominated.)

### (nominated) rust.tf/155457 *Add a new type parameter to new \`Range\` types*

Nia: Looks like a bigger thing.

Amanieu: Adding this type parameter breaks some use cases.

Nia: That alone makes me think 'no'. This requires more time to discuss, though.

Josh: 90% 'no'. But we've already shipped these types. It's 'maybe we should talk about this next week and maybe turn the 90% smaller'

### (nominated) rust.tf/155528 *const\-stabilize \`char::is\_control()\`*

Amanieu: Starting FCP.

Nia: Seems straightforward.

### (nominated) rust.tf/155114 *Add \`Step::forward/backward\_overflowing\` to enable RangeInclusive loop optimizations*

Nia: Why renominated? This is probably worth looking at in a separate meeting. Looks subtle.

Josh: I think we can count on the folks proposing this to fix the bug. I remember: the issue is that our Range types, the old ones were also the iterators, so they had to cover the ?? case themselves. ?? it's appropriate for us to panic in that scenario.

T8: It was already controversial to do that in the From impl, so this is just another case of that.

Amanieu: The end bound method for RangeBounds would return excluded self.end, now returns excluded self.start, which is always empty... (https://github.com/rust-lang/rust/pull/155114/changes/34065c211e11a45fcd72973b167845158fdde63b)

(...)

Amanieu: Seems fine. Go crater and FCP?

Josh: Agreed. If it breaks anything, we'll revert.

Amanieu: I'll reply.

### (waiting on team) rust.tf/153261 *Partially stabilize \`ptr\_alignment\_type\` as \`alignment\_type\`*

### (waiting on team) rust.tf/154905 *Derive \`Eq\`, \`Ord\`, \`Hash\` for \`MaybeDangling\`*

### (waiting on team) rust.tf/155113 *Ensure Send/Sync impl for std::process::CommandArgs*

### (waiting on team) rust.tf/155153 *Ensure Send/Sync is not implemented for std::env::Vars{,Os}*

### (new change proposal) rust.tf/libs778 *ACP: Add \`char::to\_u32\` to access underlying value*

### (new change proposal) rust.tf/libs777 *ACP \`Vec\<u8\>::push\_utf8\` for no\-memcpy UTF8 in a general bytes buffer*

### (new change proposal) rust.tf/libs775 *\`unchecked\_wrapping\_rem\` and \`checked\_wrapping\_rem\` for \`iN\`*

### (new change proposal) rust.tf/libs774 *Combined \`div\_rem\` function (and variants) for ints and uints*

### (new change proposal) rust.tf/libs773 *\`ptr::sentinel\`: \`ptr::dangling\` that cannot alias valid pointers*

### (new change proposal) rust.tf/libs771 *introduce an accessor method for \`std::fs::ReadDir\` that lets us get the path associated with the \`ReadDir\` iterator*

### (new change proposal) rust.tf/libs770 *NonZeroLayout for Allocator*

### (new change proposal) rust.tf/libs769 *Allocator: split deallocation into its own trait*

### (new change proposal) rust.tf/libs743 *ACP: Opt\-in to calling GlobalAlloc in std's internals*

### (new change proposal) rust.tf/libs688 *Initial state once cell value*

### (stalled change proposal) rust.tf/libs298 *Constructive/Destructive Interference Size Padding*

### (stalled change proposal) rust.tf/libs501 *ACP: Add floating point representation conversions*

### (stalled change proposal) rust.tf/libs191 *Add LocalWaker support*

### (stalled change proposal) rust.tf/libs457 *APC: split\_pattern on slices*

### (stalled change proposal) rust.tf/libs322 *\`AssertThreadSafe\` (name TBD) – a more general API for lifting conservative \`!Send\` or \`!Sync\` implementations*

### (stalled change proposal) rust.tf/libs331 *Support permanently skipping tests on a specific system*

### (stalled change proposal) rust.tf/libs207 *\`parse\_line\` method for \`Stdin\`*

### (stalled change proposal) rust.tf/libs549 *Add \`uNN::checked\_sub\_nonzero\`*

### (stalled change proposal) rust.tf/libs452 *ACP: Implement \`TryFromIterator\<T\>\` trait to compliment \`FromIterator\<T\>\` trait.*

### (stalled change proposal) rust.tf/libs246 *ACP: replace use of \`Pointee\` trait with a \`ptr::Metadata\` type*

_Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_