4 ms·

> Seemingly as a matter of policy, GCC has started playing very fast and loose with undefined behavior, treating it as a license to emit any code it wants or no

> Seemingly as a matter of policy, GCC has started playing very fast and loose with undefined behavior, treating it as a license to emit any code it wants or none at all, regardless of what most people would say the programmer "obviously" intended. But isn't that exactly what the C standard has said Undefined Behavior is, for as long as it has existed?

CamperBob2 3y ago
Sigh. Yes, but here on Planet Earth, a lot of legacy code was (irresponsibly) written under the assumption that the contemporary compilers wouldn't change their behavior in the future. Also here on Planet Earth, performance optimization has become much less important than not breaking older code that previously worked, but nobody told the GCC devs. Never change, HN. Keep working toward a Utopia that never was and never will be. And keep downvoting helpful hints indicating additional things to watch out for in the context of the article.
- arp242 3y ago
  Previous poster just asked a question; not everyone deals with C code, or old C code. I agree there's sometimes a certain lack of pragmatism, and that UB is used as the ultimate argument that trumps all arguments. But on the other hand, it really is UB, so that seems more of an argument for "we want a migration path" rather than "never change it until the end of time".
- uxp8u61q 3y ago
  > Sigh. Yes, but here on Planet Earth, a lot of legacy code was (irresponsibly) written under the assumption that the contemporary compilers wouldn't change their behavior in the future. Why aren't they using the old version of the compiler? Keep your unoptimized, ill-formed code if you want, while everyone else can benefit from the newest features. You can't have your cake and eat it too. Either you want to use the new stuff and you'll have to adapt your code, or you don't want the new stuff and you can keep using your code as is.
  - SomeoneFromCA 3y ago
    No need to be this passive aggresive. There is no need to break old code compatibility, while adding features into the compiler; this is how Visual Studio C++ (and most certainly Intel C++) is and always was; no surprises and excellent code quality.
  - CamperBob2 3y ago
    Keep your unoptimized, ill-formed code if you want, while everyone else can benefit from the newest features. Sadly, that's the dilemma many embedded developers eventually have to face. I'd personally like to use modern C++ features when working on a legacy codebase that I inherited. Even if I don't want or need that sort of thing, newer compilers are also better at flagging potential errors and UB (hence the article.) Overall, CPUs are much faster now, and memory is much cheaper. So I can afford to trade off a bit of overhead for better code quality and engineering discipline. And yes, newer compilers are also better at optimization, but that's literally the last thing I care about in the embedded business. I'm not targeting 8051s and 8-bit AVRs anymore. Unfortunately, what I can't afford is the time needed to review 200K+ LOCs to find all the hidden gotchas that will be exposed by newer, more aggressive compilers. There may be bugs that should have been fixed years ago, but that never surfaced. Some will trigger new warnings (again, hence the article) but will all of them be flagged? My whole point is that dealing with a broken build due to -Werror is so far down in the noise it's not even worth mentioning. If I fix the issues responsible for the new error messages and walk away thinking my job is done, well... maybe this is my lucky day, and maybe it isn't.

CamperBob2 3y ago

Sigh. Yes, but here on Planet Earth, a lot of legacy code was (irresponsibly) written under the assumption that the contemporary compilers wouldn't change their behavior in the future. Also here on Planet Earth, performance optimization has become much less important than not breaking older code that previously worked, but nobody told the GCC devs. Never change, HN. Keep working toward a Utopia that never was and never will be. And keep downvoting helpful hints indicating additional things to watch out for in the context of the article.

arp242 3y ago
Previous poster just asked a question; not everyone deals with C code, or old C code. I agree there's sometimes a certain lack of pragmatism, and that UB is used as the ultimate argument that trumps all arguments. But on the other hand, it really is UB, so that seems more of an argument for "we want a migration path" rather than "never change it until the end of time".
uxp8u61q 3y ago
> Sigh. Yes, but here on Planet Earth, a lot of legacy code was (irresponsibly) written under the assumption that the contemporary compilers wouldn't change their behavior in the future. Why aren't they using the old version of the compiler? Keep your unoptimized, ill-formed code if you want, while everyone else can benefit from the newest features. You can't have your cake and eat it too. Either you want to use the new stuff and you'll have to adapt your code, or you don't want the new stuff and you can keep using your code as is.
- SomeoneFromCA 3y ago
  No need to be this passive aggresive. There is no need to break old code compatibility, while adding features into the compiler; this is how Visual Studio C++ (and most certainly Intel C++) is and always was; no surprises and excellent code quality.
- CamperBob2 3y ago
  Keep your unoptimized, ill-formed code if you want, while everyone else can benefit from the newest features. Sadly, that's the dilemma many embedded developers eventually have to face. I'd personally like to use modern C++ features when working on a legacy codebase that I inherited. Even if I don't want or need that sort of thing, newer compilers are also better at flagging potential errors and UB (hence the article.) Overall, CPUs are much faster now, and memory is much cheaper. So I can afford to trade off a bit of overhead for better code quality and engineering discipline. And yes, newer compilers are also better at optimization, but that's literally the last thing I care about in the embedded business. I'm not targeting 8051s and 8-bit AVRs anymore. Unfortunately, what I can't afford is the time needed to review 200K+ LOCs to find all the hidden gotchas that will be exposed by newer, more aggressive compilers. There may be bugs that should have been fixed years ago, but that never surfaced. Some will trigger new warnings (again, hence the article) but will all of them be flagged? My whole point is that dealing with a broken build due to -Werror is so far down in the noise it's not even worth mentioning. If I fix the issues responsible for the new error messages and walk away thinking my job is done, well... maybe this is my lucky day, and maybe it isn't.