To save C, we must save ABI
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.<p>Could someone explain what they're actually driving at?<p>> Just a type change! Shouldn’t change the assembly too much, right?<p>What reasonable person would think that? You're changing something from 64 bits wide to 128 bits wide. Of <i>course</i> 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?<p>Who would ever expect that you could just change the width of the inputs and return type of a function and expect it <i>not</i> to break the ABI?<p>> 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<p>Of course. Why wouldn't you think that?<p>> 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?<p>Alright, I'm almost intrigued enough to keep reading. I hope they get to the point soon though.<p>> [pages and pages about linux package maintainers and red herrings about python and C++]<p>> [going on and on about "the problem" without having ever made it explicit]<p>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 <i>too much</i> time-wasting cruft here.