Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust #44930

aturon · 2017-09-29T17:49:45Z

This is a tracking issue for the RFC "Support defining C-compatible variadic functions in Rust" (rust-lang/rfcs#2137).

Steps:

Implement the RFC (PR Support defining C compatible variadic functions #57760)
Adjust documentation (see instructions on forge)
Stabilization PR (see instructions on forge)

Unresolved questions:

"When implementing this feature, we will need to determine whether the compiler
can provide an appropriate lifetime that prevents a VaList from outliving its
corresponding variadic function."
Continuing bikeshed on the ... syntax.
Ensure that even when this gets stabilized for regular functions, it is still rejected on const fn.
What even is the semantics of this? What exactly is allowed and disallowed? Would be good to have a Miri implementation.
borrowck problems: Poor interaction between NLL-borrowck, async, and c_variadic's ... desugaring (VaListImpl<'_>) #125431
What exactly are the ABI requirements around variadic calls? What are the ABI compatibility rules? Do we have to be concerned about LLVM target features affecting variadic ABI?
Soundness bug: Varargs are completely unchecked if passed as generics #61275
VaList<'_> does not carry its ABI in its type #141618

The text was updated successfully, but these errors were encountered:

plietar · 2017-09-29T18:15:03Z

I'd like to work on this, I already have some prototype

aturon · 2017-09-29T18:19:55Z

Awesome @plietar! It'd probably be good to bring this up in the "middle-end" compiler working group channel, which would also be a good place to get any help you might need.

joshtriplett · 2017-11-23T16:15:54Z

@plietar How goes the implementation? I remember you showing a mostly complete prototype on IRC.

thedataking · 2018-02-14T22:06:07Z

@plietar any news to share? This is a blocker for teams working on C to Rust transpilers, so this addition would be very welcome. (I'm part of one such team).

plietar · 2018-02-22T22:53:48Z

Hey,
Sorry I've been busy and then forgot about this. I'll get my prototype back in shape, hopefully by this weekend.

harpocrates · 2018-03-16T18:01:01Z

@plietar Any update on this? Do you have a WIP branch I can check out to try / fiddle with this?

dlrobertson · 2018-03-20T14:04:02Z

Looks like I'm a little late to the party 😄 ... sorry about that

A few questions:

How would functions that use a va_list multiple times work without the ability to explicitly use va_start and va_end? Are they expected to use copy? E.g. execl typically loops through the arguments to to get argc, creats a array argv of size argc, loops through the list again populating argv, and finally call execv.
The structure of a va_list varies greatly between the architectures. The intrinsic functions work with the architecture specific structure bitcast to an i8*, but AFAIK we'll still need to define the structure. Which architectures will be expected to be supported in the first iteration? Or am I mistaken that we'll have to define the structure?

@plietar if you don't have the time to work on this any more or if there is any way I could help out, I'd be more than happy to do so. I haven't worked on rustc much, but I'd be happy to help however I can with the implementation of this.

nikomatsakis · 2018-03-20T16:55:32Z

@dlrobertson

Seems likely that @plietar doesn't have much time, though they can speak for themselves.

I've not really looked closely at what would be needed to implement this, but if you need any help, please ping me, or reach out on gitter/IRC.

dlrobertson · 2018-04-04T14:04:45Z

I've been working on this for the past two week and have

Added va_list_kind to the target specification which closely mirrors clangs TargetInfo::BuiltinVaListKind
Added Type::va_list which builds the correct structure based on the targets va_list_kind

I'm struggling a bit with understanding how to write something in libcore and link that to Type::va_list in trans. I'm currently attempting to add #[lang = "va_list"] so that I can check the def.did against the lang_items().va_list_impl() id. Does this seem correct?

Also how would you like me to break this up into PRs? My current plan was to submit a PR once I got VaList implemented (meaning functions like vprintf could be defined and tested). Then submit a second PR for implementing support for functions like printf.

libcore: Add VaList and variadic arg handling intrinsics ## Summary - Add intrinsics for `va_start`, `va_end`, `va_copy`, and `va_arg`. - Add `core::va_list::VaList` to `libcore`. Part 1 of (at least) 3 for #44930 Comments and critiques are very much welcomed 😄

dlrobertson · 2018-11-29T22:29:18Z

Now that the VaList structure is implemented and merged into master, I'm moving on to implementing variadic functions.

When any issues with the implementation of VaList are found, please ping me.

alexreg · 2018-12-09T02:37:25Z

@dlrobertson That's super. Are you implementing the ... syntax given that seems to be the consensus so far, and bikeshedding hasn't revealed a better one? (Unless I'm behind on things.)

RalfJung · 2024-11-18T07:50:13Z

On another note, there was some recent discussion of varargs on Zulip which should be helpful on writing a spec for the ABI compatibility requirements of this feature.

Turns out the complaint about a missing "env" module has nothing to do with what the word "env" probably leads you to expect. The next step towards understanding was to turn the wasm into text. There, one can see that the "env" stuff is apparently just a placeholder name this bindgen tooling is generating for when a symbol isn't found provided. Okay. So one "env" ref is getting generated for each of the printf symbols. Which are the things I declined to provide because they need variadics. Which I avoided that's behind a feature flag in rust, so needs nightly (see rust-lang/rust#44930). Okay. Well, aside from the fact the discoverability of this sucks, and the default module name that this bindgen tooling picks for this is actively misleading, and that the suckfulness of this discoverablity really fucking matters because ANY missing symbols would lead a wide variety of people and projects to this exact common sticking point... Options? Not sure. Here, I'm trying to provide the symbols, but incorrectly, and that... actually, it seems to work? And as you'll notice, these stubs were panicking unconditionally if called _anyway_, so they're evidentally not consequential to functioning of our code corpus. So if that is actually working, not hiding-more-trouble-under-a-rug that just hasn't popped out to jumpscare me again yet... okay, then we did a double barrel roll and dodged the need for rust nightly yet again, just barely. Cool. If true. Moving on. So now the browser console is dropping me this: "Uncaught InternalError: too much recursion". And points at a line of wasm that is doing... `call $func65`. Okay. I guess now I would like sourcemaps. I do not currently have sourcemaps. *sigh*

workingjubilee · 2025-05-21T10:19:08Z

A note re: "argument forwarding". It has been brought up but I do not believe that "argument forwarding" is something we should engage with. It is a GCC extension that seems to me like it will depend too much on the internals of the compiler, or be extremely target-dependent. Making it specially efficient is likely to be barred by FFI boundaries, anyways, because it essentially amounts to a request to inline the callee variable argument fn into the caller variable argument fn, so that "unpacking" the arguments only happens once.

So honestly, if you need sprintf then call vsprintf. We will become able to declare that extern "C" fn correctly with this extension, which should make that more tractable.

If it does prove implementable, then it can be done later as a further development.

joshtriplett · 2025-05-21T13:18:16Z

@workingjubilee Complete agreement. Supporting that C compiler extension does not seem at all in scope for base varargs support.

…r=workingjubilee limit impls of `VaArgSafe` to just types that are actually safe tracking issue: rust-lang#44930 Retrieving 8- or 16-bit integer arguments from a `VaList` is not safe, because such types are subject to upcasting. See rust-lang#61275 (comment) for more detail. This PR also makes the instances of `VaArgSafe` visible in the documentation, and uses a private sealed trait to make sure users cannot create additional impls of `VaArgSafe`, which would almost certainly cause UB. r? `@workingjubilee`

Rollup merge of rust-lang#141341 - folkertdev:limit-VaArgSafe-impls, r=workingjubilee limit impls of `VaArgSafe` to just types that are actually safe tracking issue: rust-lang#44930 Retrieving 8- or 16-bit integer arguments from a `VaList` is not safe, because such types are subject to upcasting. See rust-lang#61275 (comment) for more detail. This PR also makes the instances of `VaArgSafe` visible in the documentation, and uses a private sealed trait to make sure users cannot create additional impls of `VaArgSafe`, which would almost certainly cause UB. r? `@workingjubilee`

folkertdev · 2025-05-22T20:42:45Z

We need c_variadics on stable for zlib-rs, so I'm going to try and move this forward. A draft for a modified API is at

https://gist.github.com/folkertdev/47c79e2f5b03f1138db9d53be5e51ed1

Some highlights

VaListImpl is private!
VaList just has a single lifetime parameter now, which makes a lot more sense
The VaList::with_copy function and a new va_copy! macro can be used to duplicate a VaList

This all relies on a different desugaring of ..., roughly

fn foo(placeholder: i32, mut args: ...) {
    // stuff
}

// --->

fn foo(placeholder: i32) {
    let tag = core::mem::MaybeUninit::<VaListImpl>::uninit();
    unsafe { core::instrinsics::va_start(tag.as_mut_ptr()) }
    let mut args = VaList(tag.assume_init_mut())

    // stuff
}

It seems possible to make that work internally.

I think this new API is nicer, because it leaks fewer implementation details. But before we start implementation work, does anyone see issues with this direction?

pinging specifically the c2rust folks @thedataking @ahomescu, you've probably worked with the existing c_variadics most.

traviscross · 2025-05-24T23:30:55Z

@rustbot labels -I-lang-nominated

Let's fork discussion of that proposal out to:

Consider folkertdev's c_variadic proposal #141524

We'll take the nomination there.

…ubilee use `cfg_select!` to select the right `VaListImpl` definition tracking issue: rust-lang#44930 Just a bit of cleanup really. We could use `PhantomInvariantLifetime<'f>` (rust-lang#135806) to make it more precise what that `PhantomData<&'f mut &'f c_void>` marker is doing. I'm not sure how ready that feature is though, `@jhpratt` are these types good to use internally? --- Some research into the lifetimes of `VaList` and `VaListImpl`: It's easy to see why the lifetime of these types should not be extended, a `VaList` or `VaListImpl` escaping its function is a bad idea. I don't currently see why coercing the lifetime to a shorter lifetime is problematic though, but probably I just don't understand variance well enough to see it. The history does not provide much explanation: - immunant@0814087 original implementation - immunant@b9ea653 adds `VaListImpl<'f>`, but it is only covariant in `'f` - rust-lang#62639 makes `VaListImpl<'f>` invariant over `'f` (because `VaList<'a, 'f>` is already invariant over `'f`, but I think that is just an implementation detail?) Beyond that I don't see how the lifetime situation can be simplified significantly, e.g. this function really needs `'copy` to be unconstrained. ```rust /// Copies the `va_list` at the current location. pub unsafe fn with_copy<F, R>(&self, f: F) -> R where F: for<'copy> FnOnce(VaList<'copy, 'f>) -> R, { let mut ap = self.clone(); let ret = f(ap.as_va_list()); // SAFETY: the caller must uphold the safety contract for `va_end`. unsafe { va_end(&mut ap); } ret } ``` `@rustbot` label +F-c_variadic r? `@workingjubilee`

Rollup merge of #141361 - folkertdev:varargs-cfg, r=workingjubilee use `cfg_select!` to select the right `VaListImpl` definition tracking issue: #44930 Just a bit of cleanup really. We could use `PhantomInvariantLifetime<'f>` (#135806) to make it more precise what that `PhantomData<&'f mut &'f c_void>` marker is doing. I'm not sure how ready that feature is though, `@jhpratt` are these types good to use internally? --- Some research into the lifetimes of `VaList` and `VaListImpl`: It's easy to see why the lifetime of these types should not be extended, a `VaList` or `VaListImpl` escaping its function is a bad idea. I don't currently see why coercing the lifetime to a shorter lifetime is problematic though, but probably I just don't understand variance well enough to see it. The history does not provide much explanation: - immunant@0814087 original implementation - immunant@b9ea653 adds `VaListImpl<'f>`, but it is only covariant in `'f` - #62639 makes `VaListImpl<'f>` invariant over `'f` (because `VaList<'a, 'f>` is already invariant over `'f`, but I think that is just an implementation detail?) Beyond that I don't see how the lifetime situation can be simplified significantly, e.g. this function really needs `'copy` to be unconstrained. ```rust /// Copies the `va_list` at the current location. pub unsafe fn with_copy<F, R>(&self, f: F) -> R where F: for<'copy> FnOnce(VaList<'copy, 'f>) -> R, { let mut ap = self.clone(); let ret = f(ap.as_va_list()); // SAFETY: the caller must uphold the safety contract for `va_end`. unsafe { va_end(&mut ap); } ret } ``` `@rustbot` label +F-c_variadic r? `@workingjubilee`

…workingjubilee make teach_help message for cast-before-pass-to-variadic more precise r? `@workingjubilee` based on your comment [here](rust-lang#44930 (comment))

Rollup merge of #141443 - RalfJung:c-variadic-teach-help, r=workingjubilee make teach_help message for cast-before-pass-to-variadic more precise r? `@workingjubilee` based on your comment [here](#44930 (comment))

…r=workingjubilee limit impls of `VaArgSafe` to just types that are actually safe tracking issue: rust-lang#44930 Retrieving 8- or 16-bit integer arguments from a `VaList` is not safe, because such types are subject to upcasting. See rust-lang#61275 (comment) for more detail. This PR also makes the instances of `VaArgSafe` visible in the documentation, and uses a private sealed trait to make sure users cannot create additional impls of `VaArgSafe`, which would almost certainly cause UB. r? `@workingjubilee`

…ubilee use `cfg_select!` to select the right `VaListImpl` definition tracking issue: rust-lang#44930 Just a bit of cleanup really. We could use `PhantomInvariantLifetime<'f>` (rust-lang#135806) to make it more precise what that `PhantomData<&'f mut &'f c_void>` marker is doing. I'm not sure how ready that feature is though, `@jhpratt` are these types good to use internally? --- Some research into the lifetimes of `VaList` and `VaListImpl`: It's easy to see why the lifetime of these types should not be extended, a `VaList` or `VaListImpl` escaping its function is a bad idea. I don't currently see why coercing the lifetime to a shorter lifetime is problematic though, but probably I just don't understand variance well enough to see it. The history does not provide much explanation: - immunant@0814087 original implementation - immunant@b9ea653 adds `VaListImpl<'f>`, but it is only covariant in `'f` - rust-lang#62639 makes `VaListImpl<'f>` invariant over `'f` (because `VaList<'a, 'f>` is already invariant over `'f`, but I think that is just an implementation detail?) Beyond that I don't see how the lifetime situation can be simplified significantly, e.g. this function really needs `'copy` to be unconstrained. ```rust /// Copies the `va_list` at the current location. pub unsafe fn with_copy<F, R>(&self, f: F) -> R where F: for<'copy> FnOnce(VaList<'copy, 'f>) -> R, { let mut ap = self.clone(); let ret = f(ap.as_va_list()); // SAFETY: the caller must uphold the safety contract for `va_end`. unsafe { va_end(&mut ap); } ret } ``` `@rustbot` label +F-c_variadic r? `@workingjubilee`

…r=workingjubilee use custom types to clarify arguments to `emit_ptr_va_arg` tracking issue: rust-lang#44930 split out of rust-lang#141622 r? `@workingjubilee` `@rustbot` label: +F-c_variadic

…r=workingjubilee use custom types to clarify arguments to `emit_ptr_va_arg` tracking issue: rust-lang#44930 split out of rust-lang#141622 r? ``@workingjubilee`` ``@rustbot`` label: +F-c_variadic

Rollup merge of #141623 - folkertdev:va-arg-explicit-types, r=workingjubilee use custom types to clarify arguments to `emit_ptr_va_arg` tracking issue: #44930 split out of #141622 r? ``@workingjubilee`` ``@rustbot`` label: +F-c_variadic

implement `va_arg` for x86_64 systemv tracking issue: #44930 Turns out LLVM's `va_arg` is also unreliable for this target. llvm/llvm-project#141361 So, like clang, we implement our own. I used - the spec at https://gitlab.com/x86-psABIs/x86-64-ABI - the clang implementation at https://github.com/llvm/llvm-project/blob/9a440f84773c56d3803f330774acb2b4f471d5b4/clang/lib/CodeGen/Targets/X86.cpp#L3041 We can take a bunch of shortcuts because the return type of `va_list` must implement `VaArgSafe`. I also extended some of the tests, because up to 11 floats can be stored in the `reg_safe_area` for this calling convention. r? `@workingjubilee` `@rustbot` label +F-c_variadic try-job: x86_64-apple-1

aturon added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Sep 29, 2017

aturon mentioned this issue Sep 29, 2017

Support defining C-compatible variadic functions in Rust rust-lang/rfcs#2137

Merged

EPashkin mentioned this issue Dec 3, 2017

Add support for file chooser buttons gtk-rs/gtk#602

Merged

kennytm mentioned this issue Feb 12, 2018

Continue parsing function after finding ... arg #48154

Merged

ids1024 mentioned this issue Mar 14, 2018

exec functions redox-os/relibc#76

Closed

dlrobertson mentioned this issue Apr 11, 2018

libcore: Add VaList and variadic arg handling intrinsics #49878

Merged

richard-uk1 mentioned this issue Jul 18, 2018

Add webidl variadic (...) support to web-sys rustwasm/wasm-bindgen#503

Closed

Centril mentioned this issue Oct 7, 2018

Add a va_arg intrinsic rust-lang/rfcs#1455

Closed

This comment has been minimized.

Sign in to view

folkertdev mentioned this issue May 21, 2025

limit impls of VaArgSafe to just types that are actually safe #141341

Merged

folkertdev mentioned this issue May 21, 2025

use cfg_select! to select the right VaListImpl definition #141361

Merged

joshtriplett added the I-lang-nominated Nominated for discussion during a lang team meeting. label May 22, 2025

RalfJung mentioned this issue May 23, 2025

make teach_help message for cast-before-pass-to-variadic more precise #141443

Merged

folkertdev mentioned this issue May 24, 2025

va_arg miscompiles on x86_64 llvm/llvm-project#141361

Open

traviscross mentioned this issue May 24, 2025

Consider folkertdev's c_variadic proposal #141524

Open

rustbot removed the I-lang-nominated Nominated for discussion during a lang team meeting. label May 24, 2025

folkertdev mentioned this issue May 25, 2025

implement va_arg for x86_64 systemv #141538

Open

This was referenced May 26, 2025

implement va_arg for powerpc #141622

Open

use custom types to clarify arguments to emit_ptr_va_arg #141623

Merged

Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust #44930

Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust #44930

Comments

aturon commented Sep 29, 2017 • edited by workingjubilee Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

plietar commented Sep 29, 2017

Uh oh!

aturon commented Sep 29, 2017

Uh oh!

joshtriplett commented Nov 23, 2017

Uh oh!

thedataking commented Feb 14, 2018

Uh oh!

plietar commented Feb 22, 2018

Uh oh!

harpocrates commented Mar 16, 2018

Uh oh!

dlrobertson commented Mar 20, 2018

Uh oh!

nikomatsakis commented Mar 20, 2018

Uh oh!

dlrobertson commented Apr 4, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dlrobertson commented Nov 29, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexreg commented Dec 9, 2018

Uh oh!

This comment has been minimized.

This comment has been minimized.

RalfJung commented Nov 18, 2024

Uh oh!

workingjubilee commented May 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joshtriplett commented May 21, 2025

Uh oh!

folkertdev commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

traviscross commented May 24, 2025

Uh oh!

aturon commented Sep 29, 2017 •

edited by workingjubilee

Loading

dlrobertson commented Apr 4, 2018 •

edited

Loading

dlrobertson commented Nov 29, 2018 •

edited

Loading

workingjubilee commented May 21, 2025 •

edited

Loading

folkertdev commented May 22, 2025 •

edited

Loading