There's already the "..." token to signify a variadic function, which is effectively what "takes parameters that you can't list" means, although I believe it's currently defined only for at least one non-variadic argument.

Furthermore, on some architectures, vararg functions have their own distinct ABI, so (...) as a declaration is not compatible with any definition that doesn't also use (...).

The construct would be a pointless throwback to poorer type safety. Every C function call is statically typed and so is a function definition. The declaration of what is being called may tell you nothing about the argument list, but the call expression which uses that identifier will assume a static type for it, based on how it is called. The call will be compiled assuming it has a certain type, which may or may not match what is being called. There is no run time-check; if it's wrong, it's undefined behavior.

What I would like in C is a way to specify an argument list. And be able to slop them around and call functions with them later.

So perhaps foo(args) means foo takes a list of arguments unspecified.

You can approximate an argument list using compound literals as long as 0/NULL is an acceptable default value. It's a bit noisy, but it works something like this if I remember right:

    result = foo(&(struct foo_args){.arg1 = 4, .arg7 = "2"})

There are libraries for this like GNU ffcall and libffi.

Looked at those. Problem with libffi is it wasn't ported to a 32 bit arm. And the interface is 'clunkie'

I think what I want is llvm's blocks. Which isn't available in gcc.

Like va_list in vprintf ?

Yup, would totally be fine with that.