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.)

…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

…r=workingjubilee implement `va_arg` for x86_64 systemv tracking issue: rust-lang#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

Rollup merge of #141538 - folkertdev:systemv-x86_64-va_arg, r=workingjubilee 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

…jubilee implement `va_arg` for x86_64 systemv tracking issue: rust-lang/rust#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

…ngjubilee implement `va_arg` for `powerpc` tracking issue: rust-lang#44930 The llvm `va_arg` implementation is well-known to have serious limitations. Some planned changes to rust's `VaList` make it much more likely that LLVM miscompiles `va_arg`, so this PR adds support for the various powerpc targets. Now at least the targets that `core` has explicit support for will continue to work. For `powerpc` (the 32-bit variant) this implementation also fixes a bug where only up to 20 variadic arguments were supported. Locally (with qemu), these targets now pass the tests in https://github.com/rust-lang/rust/blob/master/tests/run-make/c-link-to-rust-va-list-fn/checkrust.rs. That test does not actually run for the powerpc targets in CI though. The implementation is based on clang: - handling of big endian architectures https://github.com/llvm/llvm-project/blob/3c8089d1ea53232d5a7cdc33f0cb43ef7d6f723b/clang/lib/CodeGen/ABIInfoImpl.cpp#L191-L193 - 64-bit https://github.com/llvm/llvm-project/blob/3c8089d1ea53232d5a7cdc33f0cb43ef7d6f723b/clang/lib/CodeGen/Targets/PPC.cpp#L969 - 32-bit https://github.com/llvm/llvm-project/blob/3c8089d1ea53232d5a7cdc33f0cb43ef7d6f723b/clang/lib/CodeGen/Targets/PPC.cpp#L430 cc `@daltenty` (target maintainer) r? `@workingjubilee` `@rustbot` label: +F-c_variadic

Rollup merge of #141622 - folkertdev:powerpc-va_arg, r=workingjubilee implement `va_arg` for `powerpc` tracking issue: #44930 The llvm `va_arg` implementation is well-known to have serious limitations. Some planned changes to rust's `VaList` make it much more likely that LLVM miscompiles `va_arg`, so this PR adds support for the various powerpc targets. Now at least the targets that `core` has explicit support for will continue to work. For `powerpc` (the 32-bit variant) this implementation also fixes a bug where only up to 20 variadic arguments were supported. Locally (with qemu), these targets now pass the tests in https://github.com/rust-lang/rust/blob/master/tests/run-make/c-link-to-rust-va-list-fn/checkrust.rs. That test does not actually run for the powerpc targets in CI though. The implementation is based on clang: - handling of big endian architectures https://github.com/llvm/llvm-project/blob/3c8089d1ea53232d5a7cdc33f0cb43ef7d6f723b/clang/lib/CodeGen/ABIInfoImpl.cpp#L191-L193 - 64-bit https://github.com/llvm/llvm-project/blob/3c8089d1ea53232d5a7cdc33f0cb43ef7d6f723b/clang/lib/CodeGen/Targets/PPC.cpp#L969 - 32-bit https://github.com/llvm/llvm-project/blob/3c8089d1ea53232d5a7cdc33f0cb43ef7d6f723b/clang/lib/CodeGen/Targets/PPC.cpp#L430 cc `@daltenty` (target maintainer) r? `@workingjubilee` `@rustbot` label: +F-c_variadic

…y-speed, r=nnethercote C-variadic functions must be unsafe tracking issue: rust-lang#44930 A function that uses `...` is always unsafe to call, because it is UB to provide the wrong number of arguments, or arguments of an unexpected type. Hence, an `unsafe extern "C" { /* ... */ }` block should not be able to declare a `safe fn` that uses `...`. cc `@joshtriplett` `@workingjubilee` I'm not really sure who'd be a good reviewer for the actual parser code. `@rustbot` label: +F-c_variadic

aturon added B-RFC-approved C-tracking-issue T-lang 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

joshtriplett added the I-lang-nominated 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 label May 24, 2025

folkertdev mentioned this issue May 25, 2025

implement va_arg for x86_64 systemv #141538

Merged

This was referenced May 26, 2025

implement va_arg for powerpc #141622

Merged

use custom types to clarify arguments to emit_ptr_va_arg #141623

Merged

folkertdev mentioned this issue May 29, 2025

C-variadic functions must be unsafe #141733

Open

folkertdev mentioned this issue May 31, 2025

improve core::ffi::VaList #141835

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

aturon commented Sep 29, 2017 •

edited by workingjubilee

Loading

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!

dlrobertson commented Nov 29, 2018 •

edited

Loading

Uh oh!

alexreg commented Dec 9, 2018

Uh oh!

folkertdev commented May 22, 2025 •

edited

Loading

Uh oh!

traviscross commented May 24, 2025

Uh oh!

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!

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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

folkertdev commented May 22, 2025 •

edited

Loading