Comment by ninkendo | Hacker News Reader

Comment by ninkendo | Hacker News Reader

This is such an exhausting article to read. Useless introduction that assumes I'm familiar with their previous articles, so many long segues and needless anecdotes, it seemingly never gets to the point. I got about halfway through and gave up looking for where the actual point is.

Could someone explain what they're actually driving at?

> Just a type change! Shouldn’t change the assembly too much, right?

What reasonable person would think that? You're changing something from 64 bits wide to 128 bits wide. Of course the compiled code from the 64-bit version is looking at a single 64-bit register, with the 128-bit version looking at multiple registers. Why is this unexpected?

Who would ever expect that you could just change the width of the inputs and return type of a function and expect it not to break the ABI?

> Okay, so in C we can break ABI just by having the wrong types on a function and not matching it up with a declaration

Of course. Why wouldn't you think that?

> What if I told you this exact problem could happen, even if the header’s code read extern long long do_stuff(long long value);, and the implementation file had the right declaration and looked fine too?

Alright, I'm almost intrigued enough to keep reading. I hope they get to the point soon though.

> [pages and pages about linux package maintainers and red herrings about python and C++]

> [going on and on about "the problem" without having ever made it explicit]

At this point I give up trying to find the author's point. What needs to be saved about the ABI specifically? I haven't found the problem they're talking about and I've given up trying to skim for it. I certainly am not going to read this whole thing verbatim because they're just too much time-wasting cruft here.

It seems as though academic writing manages to simultaneously use too many words and too many references. Few papers get to the point and cover the point convincingly when they do.

I liked Adlemen's genetic computing paper. It had tons of jargon and references but was only ~ two pages long. It's a super dense two pages if you're new to molecular biology though. I think that's what most academic writers should really be aming for but they get trained by professors/TAs measuring their papers in terms of length rather than content.

The rabbit hole of shortest successful PhD thesis's is pretty cool

Standardise alias in order to unstick library evolution

What is currently not possible, which alias will fix? That’s what I couldn’t get out of the article.

If the answer is “the ability to change the types of library functions without changing their name” (which is what his first few examples were showing to be the “problem”), then of course you can’t do that, and I’m not convinced we should waste any time or effort trying to get that to work. If you want to change the types accepted/returned by a function, make a new function with a new name.

Of course, if there’s something I’m missing here I’d love to know… the article has done a terrible job outlining it if that’s the case.

Backwards compatibility is holding the evolution of C and C++ back. Design improvements can't get approved if they affect ABI. Many of those improvements affect performance. The ecosystem needs a way to move forward without breaking ABI.

I guess I’ll have to take your word for it… this article has failed to make that case IMO.

C++ shouldn't be a problem? Just add a new namespace:

std::move_fast_and_break_things::vector

Or maybe the other way around so you can keep using std::vector: move_fast_and_break_things::std::vector

Then you can add a 'using namespace move_fast_and_break_things;' at the top of your files if you know you don't care about the ABI in your program.

In c++ you do this with inline namespaces (change the default inline namespace version, keep the old one around, everything continues to work correctly in theory).

You can do that with boost:: or absl:: right now. No need to involve the standards committee at all.

This doesn't just apply to stl, this also means breaking boost or w/e and you're stuck with the same problem, users are mad and pitted against library writers.

Boost doesn't even have a stable API commitment, let alone a stable ABI. Every release may require involvement from users to keep up to date.

Abseil doesn't even have releases any more. They expect you to live at head like GOOG does internally.

It's not just new and breaking things, it also applies to fixing bugs.

The main issue is that even though C has typedefs like intmax_t that are supposed to help implementations modify them depending on compiler and platform support, in practice, ABI requirements force these typedefs never to change if programs ever link to external functions with them. This can also be seen in time_t, which could not easily be switched to 64 bits due to existing interfaces that expect 32-bit time_t values.

For how transparent aliases help solve this, suppose that there is some ancient library function called get_year:

  typedef int32_t time_t;
  int get_year(time_t time);
  // document time_t and get_year

Then, library users will call get_year with 32-bit time_t values. But suppose that eventually, as Y2038 draws near, the library writers want get_year (and related functions) to instead take 64-bit time_t for all newly compiled programs that use get_year. Previously, this was impossible: users would have to modify their programs to call a new version of every function, or link to a new version of the library. But with transparent aliases, library writers can simply replace the headers with:

  typedef int64_t time_t;
  int get_year_v2(time_t time);
  _Alias get_year = get_year_v2;
  // document time_t and get_year

Now, existing compiled programs continue to call get_year in the library, which remains implemented for compatibility. Meanwhile, newly compiled programs instead call get_year_v2, without having to modify their source code at all! This enables types such as time_t and intmax_t to be transitioned without breaking any code.

The problem I see with that is what happens if you have dynamic library C (globe) and application A that’s rebuilt but library B (which sits between A and C) hasn’t. Now you have a linking error. What happens if you rebuild B and C but A hasn’t been rebuilt. That means B still needs to know to set up aliases for back compat (which you won’t find out until runtime). What if library B is yielding the changed ABI type and A is feeding it to C?

I think it’s a useful tool but I don’t think it’s an ABI versioning panacea (even c++ adoption of inline namespaces within libraries is limited with the standard library being the only place I’ve seen it used in a meaningful way).

the solution is to stop linking libraries globally

Then you raise the number of libraries in your program to some power > 1, due to the proliferation of versions. Hope you're using compile-time LTO with code deduplication!

Most libraries are not shared, even when they are ostensibly "shared" libraries. Plus disk is cheap, it seems dumb to optimize for it in the 21st century.

You don't need LTO for dead code elimination.

A number of libraries are in fact shared. And RAM is not cheap when considered across the entire OS, and if every process has their own copy of the library, that’s a lot of RAM eaten up by needless duplication.

Is that necessarily true in a world of zram?

CPU cycles are still quite expensive, I assure you. It adds up.

It's negligible, for example : https://drewdevault.com/dynlib

IMHO, the real solution is to avoid exposing opaque types from library C in the interface of library B. Obviously, some libraries do this anyway, so your criticism is valid. Library C's headers would likely need some #define to link to the old functions and types for compatibility. But transparent aliases are still very effective in the case of shallow dynamic-library dependency graphs (e.g., most open-source projects), even if, as you note, they aren't a panacea. (I'm not even sure there is one: there'll always be a Y2038 bug or TLS deprecation or whatever that library C needs to make a breaking change to fix.)

You should mention that libraries already do this! That is a major argument for this proposal. Some libs already have these levels of indirection, this just adds it to the langauge as opposed to having to use pragmas or __attribute__((alias("_blah"))) everywhere.

Its not nearly enough to cover scalar arguments. You've got to cover composite arguments. time_t, fileno_t, fpos_t, etc may appear in structs, arrays, etc.

typedef int64_t time64_t;

And the new code adopts get_year_64 directly and you don’t blow up system complexity with features that you don’t really need.

The point is to get rid of the old crappy function, replacing it with the new better function, in new code while allowing old code to keep working.

Old functions should not have first mover advantages on names, nobody wants to riddle their function calls with *_v2 all over the place, and neither do library maintainers want people to keep using *_v2 when *_v3 fixes issues present in *_v2.

You're willing to type a multiparagraph complaint about the article being too long winded and yet balk at the TL;DR. A little patience could help, crtl-f'ing for alias and skimming a little more to find out why it's needed might be enough.

I agree there's a lot of fluff in the article but complaining even more when someone goes out of their way to appease you is just too much.

Maybe you're not the target audience. I quite enjoyed it.

This person seems to have some influence over C standards.

In fact, he is the project editor: https://thephd.dev/editing-the-c-standard

He is also the author of sol2, arguably the best C++ Lua bindings library out there :-)

His writing style might be a bit idiosyncratic, but he certainly is a brilliant person.

That is really unfortunate given that they can’t seem to communicate concisely and clearly if this article is anything to go by.

This is his personal blog. He is perfectly capable of writing concise technical proposals.

See also https://thephd.dev/portfolio/standard

Reply on news.ycombinator.com