Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • > // Proposed: Transparent Aliases > _Alias g = f;

    I think defining a constant function pointer should work. As long the compiler doesn't store this pointer in the result executable and optimizes-out all calls via it into calls to the source function.

    by Panzerschrek
  • Should have a (2022) in the title, not that anything has changed (AFAIK), but the sky didn't fall either ;)

    In the end, OS/CPU combinations define ABIs, compiler toolchains (no matter what language) can't do much more then follow (if they want to be able to talk to the operating system at least). E.g. if one day operating systems implement stable Rust-friendly ABIs, then C compilers will have to adapt to those conventions instead.

    by flohofwoe
  • The root cause of all C ABI problems are shared libraries. They give so much trouble with little to no benefits. Ideally no application should use them. All dependencies should be compiled from sources with the same compiler and standard library. System libraries aren't needed either, it should be possible to perform syscalls directly. In such approach no ABI incompatibility can happen.

    One may say, that shared libraries can save some space for both disk storage and RAM. But such savings aren't that huge and in some cases are even negative - if a library is linked-in, it's possible to discard unused functionality and even inline many library functions.

    by Panzerschrek
  • Previous submissions with comments:

    - 2023-06-10, 64 points, 16 comments: (https://news.ycombinator.com/item?id=36249253)

    - 2022-03-13, 175 points, 129 comments: (https://news.ycombinator.com/item?id=30660528)

    by aw1621107
  • Thousands of words that boil down to "intmax_t isn't ABI-stable". Who knew? (Everybody.)
    by codeflo
  • But the industry ultimately runs on compatibility, so I get why they do it. But if compatibility breaks, wouldn't hardware vendors die out? If you look at PLC and other hardware manufacturers, they're not even using modern coding. They're still running on old code. They say it's 'safe and certified code,' but in reality, it's just legacy code.

    Because in hardware, programmers, aside from researchers, are often paid much less and work in worse conditions compared to their software counterparts. At a software company, code is the product itself. But in manufacturing, software is treated as a cost attached to machines worth billions of dollars. While equipment and sensors keep getting updated and more expensive, the people connecting everything are seen as a cost cutting target. So hardware programmers generally have good job security, but their salaries aren't high. In that situation, asking them to learn something new instead of sticking with the old ways usually gets resistance, because they're not being properly compensated for that learning

    by jdw64
  • The famous C dilemma: we want to be as close to the machine as possible, but don't want to change anything when the machine changes
    by usrnm
  • > legacy choices when we quite literally were just not smart enough to be making permanent decisions like this

    Unnecessary hubris. I assure you the original ABI authors were plenty smart and just faced a different set of problems.

    > Our forebears are either not interested in a world without the mounting, crushing debt or just prefer not to tackle that mess right now

    The article mentions the organizational/social part of this problem, but then goes on to drop this turd.

    I can also assure you that our forebears were neither malicious or lazy; but faced the same problem this proposal does.

    I don’t like seeing such disrespect for the folks who laid out the groundwork for us.

    by davemp

Explore Birbla archives