std: allocate less memory in `current_exe` for OpenBSD by joboet · Pull Request #158183 · rust-lang/rust

joboet · 2026-06-20T17:25:23Z

This bug was introduced back in 2f42ac4 when Alex ported the current_exe implementation from C to Rust. Vec::with_capacity measures capacity in the number of elements, but sysctl measures it in bytes, so we need to do some conversions.

CC @semarie

rustbot · 2026-06-20T17:25:28Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @ChrisDenton, libs
@ChrisDenton, libs expanded to 12 candidates
Random selection from Darksonn, Mark-Simulacrum, clarfonthey, jhpratt

semarie · 2026-06-20T20:10:33Z

it seems a bit over engineered to me : sizeof(char) is 1 on all platforms that OpenBSD support.
it isn't a strong objection, but I would like to understand the rational.

joboet · 2026-06-20T20:49:25Z

Yes, but this isn't about an array of characters but of pointers, and size_of::<*mut c_char>() definitely isn't 1.

workingjubilee · 2026-06-20T23:11:47Z

@@ -234,11 +234,17 @@ pub fn current_exe() -> io::Result<PathBuf> {
    unsafe {
        let mut mib = [libc::CTL_KERN, libc::KERN_PROC_ARGS, libc::getpid(), libc::KERN_PROC_ARGV];


Studying https://man.openbsd.org/sysctl.2#KERN_PROC_ARGS

...So uh is there a reason, since we have to make two sysctl calls, that we don't just ask for KERN_PROC_NARGV the first time?

...though "KERN_PROC_NARGV and KERN_PROC_NENV return the number of elements as an int in the argv or env array." has got to be the most curious phrasing possible for that.

View changes since the review

Mark-Simulacrum · 2026-06-21T19:47:11Z

-        let mut argv = Vec::<*const libc::c_char>::with_capacity(argv_len as usize);
+        // ... allocate a buffer for it ...
+        let mut argv =
+            Vec::<*const libc::c_char>::with_capacity(argv_len / size_of::<*const libc::c_char>());


Should we checked_div_exact and panic here just in case? I guess it seems a bit unlikely that this goes wrong (and would be a platform/libc bug anyway).

View changes since the review

Yeah, why not...

Mark-Simulacrum · 2026-06-21T19:55:25Z

r=me if you're happy

joboet · 2026-06-21T23:21:39Z

@semarie (since you added this in fcb30a0) do you remember why this checks for dots? Spawning ".my-executable" will still result in it being looked up in the PATH, which I'd have thought is the difference between the two branches here...

View changes since the review

I think the original intent of the C code was to checking if argv0 was starting with "./"

/* get realpath if possible */ if ((argv[0] != NULL) && ((*argv[0] == '.') || (*argv[0] == '/') || (strstr(argv[0], "/") != NULL)))

but yeah, it doesn't seems right. checking if argv0 contains "/" should be enough

Mark-Simulacrum

@rustbot label +I-libs-api-nominated

This changes the behavior of std::env::current_exe on OpenBSD to not attempt to canonicalize an argv[0] if it starts with .. Previously we would canonicalize both if it starts with . or if it contains / anywhere in the path, now only the latter is checked.

IMO this is eminently reasonable and we should make the change, but in theory it seems plausible that some program is broken by this. (I suspect it's more likely that some programs are fixed by it, but hard to say).

View changes since this review

Mark-Simulacrum · 2026-06-28T21:34:15Z

        }
        let argv0 = CStr::from_ptr(argv[0]).to_bytes();
-        if argv0[0] == b'.' || argv0.iter().any(|b| *b == b'/') {
+        if argv0.iter().any(|b| *b == b'/') {


I guess technically we should FCP this breakage, let me nominate for libs-api to decide.

We discussed this in the @rust-lang/libs-api meeting and consider this a bug fix, not something that needs an FCP. There's no reason to check for a leading ., this doesn't determine whether a string represents a relative or absolute path.

Mark-Simulacrum · 2026-07-04T16:05:22Z

@bors r+ rollup

rust-bors · 2026-07-04T16:05:25Z

📌 Commit db9b6a1 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.

@semarie

…-Simulacrum std: allocate less memory in `current_exe` for OpenBSD This bug was introduced back in 2f42ac4 when Alex ported the `current_exe` implementation from C to Rust. `Vec::with_capacity` measures capacity in the number of elements, but `sysctl` measures it in bytes, so we need to do some conversions. CC @semarie

@semarie

…-Simulacrum std: allocate less memory in `current_exe` for OpenBSD This bug was introduced back in 2f42ac4 when Alex ported the `current_exe` implementation from C to Rust. `Vec::with_capacity` measures capacity in the number of elements, but `sysctl` measures it in bytes, so we need to do some conversions. CC @semarie

@semarie

…-Simulacrum std: allocate less memory in `current_exe` for OpenBSD This bug was introduced back in 2f42ac4 when Alex ported the `current_exe` implementation from C to Rust. `Vec::with_capacity` measures capacity in the number of elements, but `sysctl` measures it in bytes, so we need to do some conversions. CC @semarie

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 20, 2026

rustbot assigned Mark-Simulacrum Jun 20, 2026

workingjubilee reviewed Jun 20, 2026

View reviewed changes

Mark-Simulacrum approved these changes Jun 21, 2026

View reviewed changes

joboet commented Jun 21, 2026

View reviewed changes

joboet added 2 commits June 22, 2026 17:20

std: allocate less memory in current_exe for OpenBSD

35df795

std: program names starting with a dot may not be path-like

db9b6a1

joboet force-pushed the openbsd_current_exe branch from 495d78c to db9b6a1 Compare June 25, 2026 12:49

Mark-Simulacrum approved these changes Jun 28, 2026

View reviewed changes

rustbot added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Jun 28, 2026

Amanieu removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Jun 30, 2026

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 4, 2026

jhpratt mentioned this pull request Jul 5, 2026

Rollup of 13 pull requests #158790

Closed

jhpratt mentioned this pull request Jul 5, 2026

Rollup of 12 pull requests #158793

Closed

JonathanBrouwer mentioned this pull request Jul 5, 2026

Rollup of 12 pull requests #158806

Open

		@@ -234,11 +234,17 @@ pub fn current_exe() -> io::Result<PathBuf> {
		unsafe {
		let mut mib = [libc::CTL_KERN, libc::KERN_PROC_ARGS, libc::getpid(), libc::KERN_PROC_ARGV];

Uh oh!

Uh oh!

Conversation

joboet commented Jun 20, 2026

Uh oh!

rustbot commented Jun 20, 2026

Uh oh!

semarie commented Jun 20, 2026

Uh oh!

joboet commented Jun 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

workingjubilee Jun 20, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum Jun 21, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joboet Jun 21, 2026

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum commented Jun 21, 2026

Uh oh!

joboet Jun 21, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

semarie Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

semarie Jun 25, 2026

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum Jun 28, 2026

Choose a reason for hiding this comment

Uh oh!

Amanieu Jun 30, 2026

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum commented Jul 4, 2026

Uh oh!

rust-bors Bot commented Jul 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

joboet commented Jun 20, 2026 •

edited

Loading

workingjubilee Jun 20, 2026 •

edited by rustbot

Loading

Mark-Simulacrum Jun 21, 2026 •

edited by rustbot

Loading

joboet Jun 21, 2026 •

edited by rustbot

Loading

semarie Jun 25, 2026 •

edited

Loading

Mark-Simulacrum left a comment •

edited by rustbot

Loading