4 ms·

How can it be this was reported almost two years ago and nothing has been done?

Kenji 9y ago
Show me a program that someone used in production that became unstable because of this bug, and I will give you the answer to your question ;)
DoofusOfDeath 9y ago
I imagine it's because those who maintain GCC have varying agendas for prioritizing their contributions. The fact that is hasn't been fixed yet may be a signal that, in practice, this hasn't bitten anyone hard enough to motivate a patch submission. In which case, one could argue that the bugs are being tackled in a somewhat rational order. It may be instructive to consider why you yourself haven't submitted a fix. Perhaps that reason is common across many of those capable of submitting a fix.
- dsharlet 9y ago
  I really disagree with this. I work on compilers, so I feel for the people who work on GCC, but, I think it is totally unreasonable to expect the average GCC user who might have encountered this bug to be capable of fixing this themselves. I hacked around in clang for a bit for a compiler project. I think it would have taken me weeks or months to get to the point where I was able to fix the equivalent bug (if it existed) in Clang. Compilers are big, hard to debug projects. And, IMHO, the Clang/LLVM code is much more approachable than GCC. Not all developers are hobbyists that can afford to detour from their work for weeks or months to ramp up on GCC to fix this. I'd also point out that this is the kind of bug that could exist and be triggering in a lot of code as we speak but no one (besides the author of this blog post) have caught it. I think it's insane to ignore a bug like this.
  - boomlinde 9y ago
    >I really disagree with this. I work on compilers, so I feel for the people who work on GCC, but, I think it is totally unreasonable to expect the average GCC user who might have encountered this bug to be capable of fixing this themselves. That's not my take on it. It doesn't read like an urge to fix it yourself, rather it's literally an urge to consider why you haven't, in order to understand why others also have not. "Not all developers are hobbyists that can afford to detour from their work for weeks or months to ramp up on GCC to fix this" seems like an appropriate response and probably more or less the point that the GP wanted to make.
    - _pmf_ 9y ago
      I think "fix yourself" in this context means implementing a workaround in your code, not fixing GCC.
      - boomlinde 9y ago
        I don't think it does. ambrop7, DoofusOfDeath and dsharlet are IMO quite obviously talking about patching the GCC codebase and go out of their way to talk about the priorities of GCC maintainers, how approachable its codebase is and how hard compilers are to debug in general.
  - DoofusOfDeath 9y ago
    > I really disagree with this. I work on compilers, so I feel for the people who work on GCC, but, I think it is totally unreasonable to expect the average GCC user who might have encountered this bug to be capable of fixing this themselves. I totally agree. GCC is reputed to be a complex beast, and few people have the spare time to get to the point where they can make the fix. To clarify my original point: The bug apparently wasn't bad enough to cause anyone like yourself to either (a) fix it, or (b) pay someone else to fix it. So I'm at peace with this at a kind of meta/process level.
reallifecoder 9y ago
Any C++ programmer knows that bad things happen when throwing in a ctor. Just don't do it. This is a non problem.
- YSFEJ4SWJUVU6 9y ago
  No. Just no.
- CamperBob2 9y ago
  The RAII doctrine leaves you little choice, since the architects of C++ decided that constructors wouldn't be allowed to return NULL to indicate failure, or otherwise signal it in an easily-detectable manner. That's why I don't use RAII. It comes with a massive amount of baggage.
  - johncolanduoni 9y ago
    You can do RAII without constructors (e.g. Rust)
    - CamperBob2 9y ago
      Yep. There are any number of ways that C++ could have supported RAII without requiring either exceptions or a lot of unnecessary hacking, but they didn't.
anarazel 9y ago
Because there's actually not that many gcc developers, and very few companies support its development?
- throwaway91111 9y ago
  Yea, the core project of GNU has "very few companies" supporting it.
  - anarazel 9y ago
    GCC has a more though, there's a few people being paid to work a good chunk of their time on it.
zvrba 9y ago
A meta-comment on this: had this been a bug in VC people here would shit on Microsoft and their non-compliance to standards, not caring and so on and so on. But since it's in GCC, people are discussing a language feature.
al2o3cr 9y ago
As others have pointed out up-thread, the bug only triggers on a very specific use case - changing the body of the sample to: User u{make_1(), make_2()}; process(u); causes the first resource to be correctly destroyed.

Show me a program that someone used in production that became unstable because of this bug, and I will give you the answer to your question ;)

DoofusOfDeath 9y ago

I imagine it's because those who maintain GCC have varying agendas for prioritizing their contributions. The fact that is hasn't been fixed yet may be a signal that, in practice, this hasn't bitten anyone hard enough to motivate a patch submission. In which case, one could argue that the bugs are being tackled in a somewhat rational order. It may be instructive to consider why you yourself haven't submitted a fix. Perhaps that reason is common across many of those capable of submitting a fix.

dsharlet 9y ago
I really disagree with this. I work on compilers, so I feel for the people who work on GCC, but, I think it is totally unreasonable to expect the average GCC user who might have encountered this bug to be capable of fixing this themselves. I hacked around in clang for a bit for a compiler project. I think it would have taken me weeks or months to get to the point where I was able to fix the equivalent bug (if it existed) in Clang. Compilers are big, hard to debug projects. And, IMHO, the Clang/LLVM code is much more approachable than GCC. Not all developers are hobbyists that can afford to detour from their work for weeks or months to ramp up on GCC to fix this. I'd also point out that this is the kind of bug that could exist and be triggering in a lot of code as we speak but no one (besides the author of this blog post) have caught it. I think it's insane to ignore a bug like this.
- boomlinde 9y ago
  >I really disagree with this. I work on compilers, so I feel for the people who work on GCC, but, I think it is totally unreasonable to expect the average GCC user who might have encountered this bug to be capable of fixing this themselves. That's not my take on it. It doesn't read like an urge to fix it yourself, rather it's literally an urge to consider why you haven't, in order to understand why others also have not. "Not all developers are hobbyists that can afford to detour from their work for weeks or months to ramp up on GCC to fix this" seems like an appropriate response and probably more or less the point that the GP wanted to make.
  - _pmf_ 9y ago
    I think "fix yourself" in this context means implementing a workaround in your code, not fixing GCC.
    - boomlinde 9y ago
      I don't think it does. ambrop7, DoofusOfDeath and dsharlet are IMO quite obviously talking about patching the GCC codebase and go out of their way to talk about the priorities of GCC maintainers, how approachable its codebase is and how hard compilers are to debug in general.
- DoofusOfDeath 9y ago
  > I really disagree with this. I work on compilers, so I feel for the people who work on GCC, but, I think it is totally unreasonable to expect the average GCC user who might have encountered this bug to be capable of fixing this themselves. I totally agree. GCC is reputed to be a complex beast, and few people have the spare time to get to the point where they can make the fix. To clarify my original point: The bug apparently wasn't bad enough to cause anyone like yourself to either (a) fix it, or (b) pay someone else to fix it. So I'm at peace with this at a kind of meta/process level.

reallifecoder 9y ago

Any C++ programmer knows that bad things happen when throwing in a ctor. Just don't do it. This is a non problem.

YSFEJ4SWJUVU6 9y ago
No. Just no.
CamperBob2 9y ago
The RAII doctrine leaves you little choice, since the architects of C++ decided that constructors wouldn't be allowed to return NULL to indicate failure, or otherwise signal it in an easily-detectable manner. That's why I don't use RAII. It comes with a massive amount of baggage.
- johncolanduoni 9y ago
  You can do RAII without constructors (e.g. Rust)
  - CamperBob2 9y ago
    Yep. There are any number of ways that C++ could have supported RAII without requiring either exceptions or a lot of unnecessary hacking, but they didn't.

anarazel 9y ago

Because there's actually not that many gcc developers, and very few companies support its development?

throwaway91111 9y ago
Yea, the core project of GNU has "very few companies" supporting it.
- anarazel 9y ago
  GCC has a more though, there's a few people being paid to work a good chunk of their time on it.

zvrba 9y ago

A meta-comment on this: had this been a bug in VC people here would shit on Microsoft and their non-compliance to standards, not caring and so on and so on. But since it's in GCC, people are discussing a language feature.

al2o3cr 9y ago

As others have pointed out up-thread, the bug only triggers on a very specific use case - changing the body of the sample to: User u{make_1(), make_2()}; process(u); causes the first resource to be correctly destroyed.