Dec. 12, 2020, 8:49 a.m.

πŸ‘ˆ #0 - intmax_t and Poking at ABI

The Golden Flock

πŸ‘‹

It’s Letter #0, and we’re starting it off with a new feature idea!

If you missed one of the related articles written by our very own “ThePhD”, catch it here. Essentially, the gist of it is that C doesn’t have the built-in language tools to solve some of its most pressing existential problems. This doesn’t mean C (and, by extension, C++) can’t be used to make great APIs, it just means that C’s ability to evolve into something better and handle greater use cases it a little questionable!

For that reason, we’re thinking about actually introducing a new feature to C. We might even get to prototype it out in GCC or Clang! But, the idea is very simple. If you’re used to C++’s “type aliases” or C’s “typedefs”, then the concept here is pretty straightforward for a new feature. Here’s the core idea, using made up syntax:

int a_function (int a, int b) {
    return a + b;
}

using a_function_by_any_other_name = a_function;
// does it smell as sweet?

Essentially, it allows you to provide a “transparent” alias for a pre-existing function declaration. It allows you to interact with that transparent alias like a normal function call:

int main () {
     int value =
          a_function_by_any_other_name(3, 1);
     return value; // returns 4
}

You can even do normal things with it, like take its address or let it convert to a function pointer to pass it as an argument to another function. Note that you can get similar behavior (but not perfect) in C++ using constexpr an references:

int a_function(int a, int b) {
    return a + b;
}

constexpr const auto& by_any_other_name( = a_function;

int main() {
    return by_any_other_name(1 ,2);
}

This means it’s not totally necessary in C++. But for C β€” which lacks both constexpr and references β€” it is perhaps the only way to have a non-macro solution to “renaming” functions.

The reason being able to provide transparent aliases is you have to avoid things like Shared Libraries from containing the exact symbol by_any_other_name! This is important for ABI, for example if you wanted to direct a function call to a specific internal implementation but give the user a “standard” name to call. For example, one can map the cos global function to a implementation-specific intrinsic:

using cos = __cosf64;

This is mostly for people in the weeds of implementing heavily-depended-upon libraries, but it also comes in handy for other folk who want to make certain functions available without having to redeclare/rewrite them under a different name and use implementation-defined tricks to have them show up.

A more full specification-like sketch can be found here in this Godbolt, showing the behavior we would want overall. (It doesn’t compile, because it’s a new idea.) Maybe, one day, it will be proposed for standardization in C!

β€” Shepherd’s Oasis πŸ’™

You just read issue #0 of The Golden Flock. You can also browse the full archives of this newsletter.

Share on Facebook Share on Twitter Share via email
Brought to you by Buttondown, the easiest way to start and grow your newsletter.