4 ms·

Is that an ABI break due to the extra parameter? I skimmed the paper, but it only seemed to talk about the standard table-based unwind in passing, with no menti

Is that an ABI break due to the extra parameter? I skimmed the paper, but it only seemed to talk about the standard table-based unwind in passing, with no mention of compatibility. Did I miss something? If it is in fact an ABI break, how much of an obstacle would that be to getting this through the committee? I was also under the impression that up-to-date compilers/runtimes are not something one can take for granted in the embedded world, so recompiling everything is a shaky proposition.

gpderetta 7y ago
It is ABI breaking but there is a way out. Instead of replacing the existing exceptions, this mechanism could be used for checked exceptions only which will necessarily require annotating functions, so ABI breaks are to be expected.
- aw1621107 7y ago
  Wouldn't function annotations be an API break, too? And I'd imagine checked exceptions would get a decent amount of pushback due to Java's implementation.
  - gpderetta 7y ago
    Yes, but they are opt-in. I think, given the right abstraction capabilities they might work in C++. They are semantically no different than returning an either<T, error>.
ctz 7y ago
Is there an example where changing the exception handling system does not change the ABI?
- twic 7y ago
  Changing the handling of existing exceptions, no. But adding a new kind of exception is fine. That's what the herbceptions proposal did. However, i think they are in fact proposing to change the ABI here.
- aw1621107 7y ago
  I'm not familiar enough with the darker corners of C++ implementations to say, but I'd guess not. From what the paper describes it seems table-based exception handling is deeply ingrained into the Itanium ABI so any significant change would be an ABI break, which would make said change more difficult to spread.
  - asveikau 7y ago
    I am not sure if all implementers made the same choices, but for example I believe Microsoft concluded that table-based EH is always better and made not only their IA64 ABI but also their amd64 ABI use it. They keep 32-bit x86 at an older implementation for compatibility reasons, but any ABI introduced later gets the new thing.
    - aw1621107 7y ago
      Wait, is the Itanium ABI not the amd64 ABI? I thought that the 64-bit x86 ABI was called the Itanium ABI despite Itanium having gone kaput. Did Microsoft release a paper with that conclusion? I'd be curious to read more about their reasoning.
      - asveikau 7y ago
        Hmm, I missed the C++ism for this term. Googling around: > Although it was initially developed for the Itanium architecture, it is not platform-specific and can be layered portably on top of an arbitrary C ABI. My mistake, my comment is mostly rubbish then.
        aw1621107 7y ago
        I didn't realize it was a C++-specific thing, to be honest. I should probably try for more generic wording in the future.
steveklabnik 7y ago
> If it is in fact an ABI break, how much of an obstacle would that be to getting this through the committee? In my understanding: Historically, the committee basically said "if your paper breaks the ABI, it won't be considered, don't bother." In Prague last month, the committee voted that C++23 would not break ABI, though that decision is not final. However, they did say that authors should bring papers that would break the ABI, and they will be considered in a general sense. So, it is now possible, at least.
- aw1621107 7y ago
  That's fair. I suppose the next question would be what it would take to get the committee to stop kicking the can down the road and actually vote to break ABI, since "considered" is a fairly weak promise. Perhaps they're waiting to see what people come up with?
  - steveklabnik 7y ago
    I was not in attendance, but from what I read on /r/cpp, at least some people thought that the discussion was brought up in sort of a suboptimal way, and that there was actually a lot of support in the room for breaking the ABI. Regardless, I think that what was decided is clearly in this direction.
    - aw1621107 7y ago
      I'm curious to see where C++ will go from here on out then. If only they were open to breaking API too to fix things like unordered_map... By the way, I know Rust doesn't guarantee a stable ABI, but has Rust gotten significant improvements out of not making that guarantee?
      - steveklabnik 7y ago
        The main improvement is not spending time and energy to define such a thing and maintain it. We have done some breaking stuff too, and that has been useful, but in my mind, that’s less important.

gpderetta 7y ago

It is ABI breaking but there is a way out. Instead of replacing the existing exceptions, this mechanism could be used for checked exceptions only which will necessarily require annotating functions, so ABI breaks are to be expected.

aw1621107 7y ago
Wouldn't function annotations be an API break, too? And I'd imagine checked exceptions would get a decent amount of pushback due to Java's implementation.
- gpderetta 7y ago
  Yes, but they are opt-in. I think, given the right abstraction capabilities they might work in C++. They are semantically no different than returning an either<T, error>.

ctz 7y ago

Is there an example where changing the exception handling system does not change the ABI?

twic 7y ago
Changing the handling of existing exceptions, no. But adding a new kind of exception is fine. That's what the herbceptions proposal did. However, i think they are in fact proposing to change the ABI here.
aw1621107 7y ago
I'm not familiar enough with the darker corners of C++ implementations to say, but I'd guess not. From what the paper describes it seems table-based exception handling is deeply ingrained into the Itanium ABI so any significant change would be an ABI break, which would make said change more difficult to spread.
- asveikau 7y ago
  I am not sure if all implementers made the same choices, but for example I believe Microsoft concluded that table-based EH is always better and made not only their IA64 ABI but also their amd64 ABI use it. They keep 32-bit x86 at an older implementation for compatibility reasons, but any ABI introduced later gets the new thing.
  - aw1621107 7y ago
    Wait, is the Itanium ABI not the amd64 ABI? I thought that the 64-bit x86 ABI was called the Itanium ABI despite Itanium having gone kaput. Did Microsoft release a paper with that conclusion? I'd be curious to read more about their reasoning.
    - asveikau 7y ago
      Hmm, I missed the C++ism for this term. Googling around: > Although it was initially developed for the Itanium architecture, it is not platform-specific and can be layered portably on top of an arbitrary C ABI. My mistake, my comment is mostly rubbish then.
      - aw1621107 7y ago
        I didn't realize it was a C++-specific thing, to be honest. I should probably try for more generic wording in the future.

steveklabnik 7y ago

> If it is in fact an ABI break, how much of an obstacle would that be to getting this through the committee? In my understanding: Historically, the committee basically said "if your paper breaks the ABI, it won't be considered, don't bother." In Prague last month, the committee voted that C++23 would not break ABI, though that decision is not final. However, they did say that authors should bring papers that would break the ABI, and they will be considered in a general sense. So, it is now possible, at least.

aw1621107 7y ago
That's fair. I suppose the next question would be what it would take to get the committee to stop kicking the can down the road and actually vote to break ABI, since "considered" is a fairly weak promise. Perhaps they're waiting to see what people come up with?
- steveklabnik 7y ago
  I was not in attendance, but from what I read on /r/cpp, at least some people thought that the discussion was brought up in sort of a suboptimal way, and that there was actually a lot of support in the room for breaking the ABI. Regardless, I think that what was decided is clearly in this direction.
  - aw1621107 7y ago
    I'm curious to see where C++ will go from here on out then. If only they were open to breaking API too to fix things like unordered_map... By the way, I know Rust doesn't guarantee a stable ABI, but has Rust gotten significant improvements out of not making that guarantee?
    - steveklabnik 7y ago
      The main improvement is not spending time and energy to define such a thing and maintain it. We have done some breaking stuff too, and that has been useful, but in my mind, that’s less important.