n3329 - Transparent _Aliases

[ThePhD]

EDIT - Latest Draft: https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Transparent%20Aliases.html

---

For C. The goal is to defend against ABI by allowing function renaming. Attributes on the renaming declarations can also provide an easy-out for weak symbols.

#include <assert.h>

int real_call (double d, int i) {
    return (int)(d + i);
}

// a "typedef" for real_call;
using made_up_call = real_call;
// made_up_call never makes it into binary, it's just
// identical function pointer
_Static_assert(&made_up_call == &real_call);

int main (int, char*[]) {
    typedef int(real_call_t)(double, int);
    // decays, like normal, to function pointer to real_call
    real_call_t* made_up_call_ptr_decay = made_up_call;
    // function pointer to real_call
    real_call_t* made_up_call_ptr = &made_up_call;
    // equivalent
    assert(made_up_call_ptr_decay == &real_call);
    assert(made_up_call_ptr == &real_call);
    // invokes real_call directly
    [[maybe_unused]] int is_3 = made_up_call(2.0, 1);
    // invokes real_call through it's function pointer
    [[maybe_unused]] int is_4 = real_call_ptr_decay(3.0, 1);
    // invokes real_call through it's function pointer
    [[maybe_unused]] int is_5 = real_call_ptr(3.0, 2);
    assert(is_3 == 3);
    assert(is_4 == 4);
    assert(is_5 == 5);
    return 0;
}

[ThePhD]

This is now the _Alias paper. Article coming soon, when the art is done.

https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Transparent%20Function%20Aliases.html

[h-vetinari]

Still not on twitter, but saw your wail about how undef's might break this proposal.

It's likely I don't get all the nuances, but I was wondering: since _Alias is a new thing (despite trying to be transparent!), couldn't you just mandate an error for undef'ing an _Alias (basically an exception in 7.1.4p2)? Yes, it will make it impossible to use both old binaries and new libraries (employing _Alias) at the same time, but that sounds like a fair trade-off for rolling your own imaxabs or whatever.

[ThePhD]

The problem isn't the #undef - that's just there to show how fucked things are. The real problem is the redeclaration: that turns into a hard error right now if you're using the _Alias.

[h-vetinari]

Yeah, that's what I meant by "rolling your own". I still think my point stands though - why not forbid redeclaration of an _Alias - effectively canonicalizing that hard error? That would be a break of its transparency, but since it's new, its behaviour is up for definition. I get (I think!) this means that codebases happily redefining stuff could not be compiled against (e.g.) a newer glibc anymore - if they want, they'll have to rename their redeclared function.

I'm sure that would receive some pushback from those who redeclared stdlib-stuff and never want to touch their pustulant codebases yet still get to upgrade their dependencies indefinitely. But there comes a point where someone needs to pay for the crimes of the past (it's also not like renaming the redeclared function would be that hard); and the good thing is that it'd be a smaller group than those that "just" don't want to touch their code (but haven't redeclared critical functions).

[ThePhD]

Tabled for post-C23.

[ThePhD]

N2901.

[mentalisttraceur]

Doesn't a static function pointer already let us do this?

Sorry if this is answered somewhere, I just came here from your blog post and haven't had the time to read the proposal itself. Maybe this can serve as a nice FAQ entry for others with the same question though.

Seems to me that even as far back as C89, we could portably indirect between ABI function name and C function name like this:

int f(int x)
{
    return x - 1;
}

static int (* g)(int x) = f;

int h(int x)
{
    return g(x);
}

When I compile this with a recent clang with optimizations turned up, the g entirely disappears from the resulting object file, as if I simply didn't have it in the source and called f directly.

This seems to achieve the same goal as the proposed _Alias g = f;. You do need to explicitly repeat the function type signature, but that seems fine for something that goes into a header.

Of course, static function pointer becoming zero cost requires the compiler to implement a modest optimization - but _Alias requires implementation effort too, while that optimization is generally useful to implement and already exists in the wild.

I do realize that think "freedom for a bad implementation to needlessly store one pointer and indirect through it" is QoI wiggle room, which your blog post was strongly against, but it's just a tiny bit of performance wiggle room, not code behavior and ABI wiggle room, right?

On the other hand, I can see how having an explicit new syntax would help educate developers on this pattern, and might be useful for tooling?

Any other advantages I missed? (An "already answered in N2901" reply is fine, I'm happy to take the time to find it once I know it's in there.)