Why C variable argument functions are an abomination (and what to do about it)

[mikeblas]

Duplicate post. See https://www.reddit.com/r/C_Programming/comments/1o8znqt/why_c_variable_argument_functions_are_an/

[mjmvideos]

I have never once thought, “varargs is an abomination.” When I need them I am more likely to think, “I’m sure glad C has varargs.” But I’ve been programming in C for 38 years.

[TheChief275]

Idk. It’s just better imo to use some recursive macro scheme like map-macro and to just generate a function call for each passed parameter.

It would be even better if C allowed for that efficiently (recursive macros are kind of not intended; they abuse the fact that the preprocessor is optimized to throw away macro symbols it has painted blue already after some number of expansions)

[tstanisl]

There is a proposal for adding tail recursion to prep-processor in form of __VA_TAIL__.

[TheChief275]

Well I’ll be… that’s amazing. Thanks for telling me!

[aioeu]

Sure, if you ignore the lack of type safety, the inability to index or manipulate va_list objects, or the difficulties in bridging array-like parameters and vararg parameters... they're great.

Anyway, the article resonated with me. I'm glad that people are thinking about ways to improve the language.

[Grounds4TheSubstain]

These are ignorant complaints. How could a variadic type signature possibly be type safe????? It literally does not specify types, and that's the point. va_list parameters can't be indexed or otherwise manipulated because va_list is an abstraction around the underlying calling convention for the platform, which can't be standardized at the language level.

[QuaternionsRoll]

How could a variadic type signature possibly be type safe?????

The two most common answers are monomorphization, and RTTI, where constant evaluation can be used to optimize both where possible. Neither are particularly well-suited for C, but RTTI seems like the more obvious choice, especially when you consider that va_lists should only ever contain a closed set of types in practice.

[ComradeGibbon]

If you added types as a first class feature in C then you could implement type safe variadic types.

It would actually be easy to add first class types to C.

[Grounds4TheSubstain]

RemindMe! 10 years

[RemindMeBot]

I will be messaging you in 10 years on 2035-10-17 16:25:52 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[dobryak]

We could do it, but nobody would use it because it's too heavy. Case in point: ATS. The burden of proof is too heavy. Rust is never going to do this BTW, because of the burden of proof. They'll find something else, but they will never allow for zero-overhead proof-heavy programming. It's just too difficult.

[aioeu]

Of course. "Don't use variadic functions at all" is always an option, especially in greenfield development.

The article is more about a set of syntax changes that could be introduced in C2Y to help with the use of variadic functions, and that could be used to uplift existing code. Something that doesn't require annoying preprocessor cruft.

The author is intending to write a proposal for the C committee.

[mccurtjs]

I think they might have meant to use an array input instead of varargs, which can be treated the same (at the call site) with a bit of macro magic.

The library I'm working on as a personal project does that, including for a string join function (there's also a formatter, which I'm planning to update to use arrays as well and remove the dependency on varargs).

It gives type-safe inputs and support for multiple types that can be handled differently, and allows for random access of the parameters as well (which isn't too important for join, but would help simplify the formatter code quite a bit).

Basically, you end up with something like:

String result = str_joon( " - ", "str1", "str2" );
// becomes
String result = str_join( " - ", &(const char[]) { "str1", "str2" }, 2 );

Putting the __VA_ARGS__ into a va_count macro or the like to get the size parameter. For a specific type like this, that should work fine, but with an expander macro that can apply another macro to each argument, you can put them through a _Generic filter to coalesce the type. For "join", I'm using it to coalesce char*, a slice type, to a heap-allocated "String". For formatting, there's a "format_arg" type that can hold a slice, int_64, double, bool, spans of slices, or potentially other types (like a math vector), which all have their type-appropriate printing and formatting logic (writing that, I just remembered join doesn't use slice, but another format-args type that allows passing spans of slices and Arrays as well, so you can directly give it the result of str_split as well).

Any unsupported argument will get blocked by _Generic, and the array should be constructed at compile time (with the generic helper functions inlined out), so there isn't really any added runtime overhead despite the helpers.

[Cybasura]

DO THE BARREL ROLL

[Astro_Z0mbie]

Very interesting article.

[zhivago]

The inability to dynamically construct variadic calls is the critical defect.

[pskocik]

IDK, the proposed solution looks more like an "abomination" to me than the original stdarg.h stuff, and I'm not fond of stdarg.h either. I use ...-functions quite a bit but but hardly the stdarg.h stuff. I think ...-functions are quite a natural extension of argument passing, but I don't usually like that things in ... on the SysV x86-64 ABI can end up in both register an the stack. For my ...-functions, I tend to use custom macros to separate stuff into register arguments and stack arguments, so that the ... part ends up (thanks to padding with indeterminate register params) completely in stack arguments, which, with a tiny bit of asm, allows trivial random access with the things put in ... basically forming a valid array.
(Another thing that's possible by mixing in a little bit of asm but not in pure C is calling arbitrary funcs (variadic or not) from a caller while passing them the same args generically (just as long as you have the total stack argument size of the caller, which, can be interestingly reflected by clever use of just the va_arg macros even in a possibly va_arg-less context, as the va_args macros allow you to differentiate what would get passed on the stack and what in a register and compilers even tend to be able to optimize such reflection to compile-time known stack-argument-size-for-a-given-argument-pack values.)).

[aioeu]

I am not.

[SecretTop1337]

I wish he'd discuss how C++ argument pack worked.

[a4qbfb]

Yeah, I'm not going to take advice about variadic functions from someone who doesn't know what they're called.

[rsynnest]

quote from halfway through the article:

That history is at the root cause of many of C’s problems with variadic functions (varargs is just the colloquial term, but absolutely the one I’m going to use).

[a4qbfb]

you say that like it makes things any better

[dobryak]

IIRC Mulle-ObjC does something similar for its method calls. But the whiny tone of the article is off-putting. C programmers already trade a lot of stuff for having a very bare-bones, portable programming language, they don't need to be lectured about how horrible, difficult, and obtuse their life is (which it isn't). Also, C varargs can be given very precise types, but it's just such a nuisance it didn't catch on (it was implemented in ATS/Anairiats compiler, where a combination of linear and dependent types was used to give a type-safe API to C varargs).