Folkert de Vries

right, I also noticed that later. So, thank you for arguing your point. To make the issue explicit: to make the C example work in rust like it does in...

I guess actually more the former `PassMode::Indirect { on_stack: false, ... }` (which is in line with beetrees' PR). This is a bit non-standard because it's really a mutable reference.

Well because `VaList` is `impl Drop` it will (semantically) be used again after the call. That makes this trick unintuitive: it doesn't line up with how move semantics normally work....

To be clear, the problem you're describing is that `VaList`'s `Drop` is a no-op, but should call `va_end`? Or is there something else? I wanted to follow up on that....

> The C standard says that this is implementation-defined behaviour, which means it could be undefined. I can't find it saying so explicitly, am I missing it or does it...

Allright, summary time. I think there are 2 questions that we need a formal (T-lang?) decision on: - should the `PassMode` of `VaList` be `PassMode::Indirect { on_stack: false, ... }`?...

We already unconditionally call `va_end` (even if you `mem::forget` the `VaList` value), so it doesn't really follow the rules of `Drop` right now anyway. But for now I'll remove this...

hmm this needs some extra data types now, and reading kernel C code will need a better-rested brain. I'll continue with this tomorrow.

well I did just reproduce this locally and that library just performs an out-of-bounds lookup ``` thread 'main' panicked at library/core/src/panicking.rs:219:5: unsafe precondition(s) violated: slice::get_unchecked requires that the index is...

btw that out-of-bounds access also happens on the current `main` branch locally for me. I tried upgrading `ctest2` to the latest version, and it appears to just be broken (some...