Direct access to argc and argv?

rtfeldman · September 6, 2023, 12:16am

I have an unusual topic that it seems like (understandably!) not many people are talking about.

I know every process on UNIX and Windows has argc and argv stored in the stack portion of the process's memory. I also know that Rust doesn't have an option to access these directly from a normal main; instead, it converts them to OsString and then exposes those via std::env::args().

I'd like to access these because they point to strings which are already encoded in the exact form I need (e.g. null-terminated utf-8 on UNIX, null-terminated widechar on Windows) for passing to some C functions via FFI which expect that format anyway.

I'd like to avoid having Rust convert them from the format I already need into a format I don't need (OsString, which isn't null-terminated and doesn't store widechar on Windows) and then have to take that OsString and convert it back into a null-terminated OS-appropriate string...when the process's stack memory has the data in the exact format I already wanted right there!

I do realize that from a performance perspective this is not a big deal in practice, but it bugs me enough that I've gone searching for a way to get direct access to argc and argv without having to go through OsString. This works, but with an unfortunate downside:

#![no_main]

#[cfg(target_os = "macos")] // other targets need other symbols
#[no_mangle]
pub extern "C" fn main(argc: i32, argv: *const *const u8) -> i32 {
    // ...code goes here
}

This totally works, but it has the unfortunate downside that none of Rust's normal runtime setup logic runs. One consequence of this is that panics abort after printing the message (including the backtrace if RUST_BACKTRACE=1 is set) followed by "fatal runtime error: failed to initiate panic, error 5". I think it might actually be UB.

Does anyone have any info on this topic? I couldn't find a language proposal about direct access to argc and argv, and the workaround I have now isn't worth it because it requires skipping the runtime setup (which I don't want to skip). I'd appreciate any ideas for how to get this to work!

quinedot · September 6, 2023, 12:42am

I think this is the intended feature. But see also. I don't know much about the details (like what else you're missing out on -- the panic handler at least it seems from that issue, and wouldn't surprise me if there's more), so consider this a hint towards something to research more and not necessarily the end answer.

You can certainly cause UB with no_mangle.

github.com/rust-lang/rust

#[no_mangle] is unsafe

opened 11:36PM - 02 Sep 15 UTC

geofft

A-linkage P-low T-lang T-compiler I-unsound C-bug

On some platforms (at least GNU/Linux, but I hear Windows and several others too…), if you link together two static libraries that both export a symbol of the same name, it's undefined which symbol actually gets linked. In practice on my machine, the first library seems to win. This lets you defeat type/memory safety without the `unsafe` keyword, by having two crates export a `#[no_mangle] pub fn` with different signatures but compatible calling conventions: ``` rust // one.rs #![crate_type = "lib"] #[no_mangle] pub fn convert(x: &'static i32) -> Result<i32, f32> { Ok(*x) } ``` ``` rust // two.rs #![crate_type = "lib"] #[no_mangle] pub fn convert(x: &'static f32) -> Result<i32, f32> { Err(*x) } ``` ``` rust // transmute.rs extern crate one; extern crate two; fn main() { static X: f32 = 3.14; let y: i32 = two::convert(&X).unwrap(); println!("{}", y); } ``` ``` geofft@titan:/tmp/transmute$ rustc one.rs geofft@titan:/tmp/transmute$ rustc two.rs geofft@titan:/tmp/transmute$ rustc transmute.rs -L . geofft@titan:/tmp/transmute$ ./transmute 1078523331 ``` Despite the stated call to `two::convert`, it's actually `one::convert` that gets called, which interprets the argument as a `&'static i32`. (It may be clearer to understand with this [simpler example](https://gist.github.com/geofft/493c5c17bfdd04b97670), which doesn't break type safety.) On at least GNU/Linux but _not_ other platforms like Windows or Darwin, dynamically-linked symbols have the same ambiguity. I don't know what the right response is here. The following options all seem pretty reasonable: 1. Acknowledge it and ignore it. Maybe document it as a possible source of unsafety, despite not using the `unsafe` keyword. 2. Have `#[no_mangle]` export both a mangled and un-mangled name, and have Rust crates call each other via mangled names only, on the grounds that `#[no_mangle]` is for external interfaces, not for crates linking to crates. ("External interfaces" includes other Rust code using FFI, but FFI is unsafe.) This is analogous to how `extern "C" fn`s export both a Rust-ABI symbol as well as a C-ABI shim, and a direct, safe Rust call to those function happens through the Rust ABI, not through the C ABI. I'm pretty sure that all production uses of `#[no_mangle]` are `extern "C"`, anyway (see e.g. #10025). 3. Deprecate `#[no_mangle]` on safe functions and data, and introduce a new `#[unsafe_no_mangle]`, so it substring-matches `unsafe`. (`#[no_mangle]` on unsafe functions or mutable statics is fine, since you need the `unsafe` keyword to get at them.) All of these are, I think, backwards-compatible.

Coding-Badly · September 6, 2023, 4:03am

For Windows, is there a reason you can't use GetCommandLineW + CommandLineToArgvW?

I suspect that's not true for Windows processes. I vaguely recall that Windows processes don't even have a return-to-operating system address on the stack; that calling ExitProcess is required to avoid a fault.

rtfeldman · September 6, 2023, 10:45am

TIL about GetCommandLineW, thanks for the link!

I guess technically Windows stores it in the PEB portion of the process's memory rather than the stack, but I didn't know you could call a (non-syscall) function to access it!

I know about macOS's _NSGetArgc() and _NSGetArgv(), but as far as I'm aware, the only way to do something like that on Linux is reading /proc/self/cmdline, which requires a syscall that could easily be more costly than doing the redundant conversions.