5 ms·

What's the problem of using toolchain-specific features instead of behavior defined by the standard? Isn't this the bread and butter of embedded development and

What's the problem of using toolchain-specific features instead of behavior defined by the standard? Isn't this the bread and butter of embedded development and the reason why some behavior is purposely left undefined in the standard?

eru 2y ago
> [...] and the reason why some behavior is purposely left undefined in the standard? It's one of the saner reasons why there's UB in C and C++. But there's lots of crazier reasons.
- motorest 2y ago
  > It's one of the saner reasons why there's UB in C and C++. It is the reason why the standard purposely leaves some areas undefined. C and C++ detractors talk a lot about UB but they always show their understanding on the subject is at best superficial. The parrot UB as if it was this major gotcha, when it is literally behavior the standardization committees make a call to not define behavior to purposely leave it open, so that any implementation can still be conforming even if they decide to implement behavior not defined in the standard. It is that simple, but somehow people parrot UB behavior as if it was this major gotcha. Baffling.
  - pjmlp 2y ago
    Baffling is the ignorance in the ways of WG14 and WG21, while pretending to be a know it all, maybe update yourself on the relevant papers for C2y and C++26, aimed at clearing up references to UB with erranous behaviour, or implementation defined.
    - formerly_proven 2y ago
      This subthread is kinda strange with people claiming IB and UB are the same, considering that C/C++ have had clearly delineated definitions of undefined behavior versus implementation-defined behavior for decades in their term definitions.
      - grandempire 2y ago
        No, we do understand the difference and the comment still stands. UB is a choice by the standard committee. Signed integer overflow is undefined because it’s not even clear if you can detect it happens in all implementations. Do you want a conditional after every integer add?
        eru 2y ago
        > Signed integer overflow is undefined because it’s not even clear if you can detect it happens in all implementations. Do you want a conditional after every integer add? Huh? You can just make it implementation defined, and most implementations would declare it to work like twos-complement wrap-around. Just like unsigned integer overflow is already defined in the standard. Where does the conditional you are talking about come from? Unsigned integer overflow doesn't have any conditionals either. Compilers like GCC already support wrap-around for signed integers with a command line option. It's spelled "-fwrapv", and I don't think it involves any conditionals.
        grandempire 2y ago
        > You can just make it implementation defined No you can't. Let me repeat again. One very possible implementation is to crash on signed integer overflow (`-ftrapv`). But if it cannot easily detect it, then it must either: a) check every integer add. b) use some less reliable detection method (random sampling, etc). To be well defined means the implementation will reliably do the same thing. A procedure which sometimes does one thing or another, is not well defined. > Unsigned integer overflow doesn't have any conditionals either. That's because there is no detection needed. The instruction set for unsigned integers is designed to do that. > -fwrapv Here is the documentation: > This option instructs the compiler to assume that signed arithmetic overflow of addition, subtraction and multiplication wraps around using twos-complement representation. https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html What this means is that if your hardware wraps on signed integer overflow, you can tell GCC that you are perfectly happy with that behavior. Then GCC understands and will handle it just fine. If your hardware does something else, `fwrapv` will not help you.
    - grandempire 2y ago
      You are upset we aren’t familiar with papers and proposals which are not yet agreed on as standard? And for unreleased C++ versions?
      - jenadine 2y ago
        What's upsetting is comments that confidently state inaccurate or clearly wrong statements, thereby spreading misconceptions
        motorest 2y ago
        > What's upsetting is comments that confidently state inaccurate or clearly wrong statements, thereby spreading misconceptions The bulk of the people in this thread clearly have no grasp of what UB is, even though they are very vocal in the way they parrot their misconceptions and outright absurdities. They would never write half the absurd and misguided claims they did if they were even aware the standards explicitly use the term "non-portable" to define UB.
      - pjmlp 2y ago
        Nah, thankfully liability legislation is finally happening so folks will actually bother to learn standards and how compilers approach them. Or eventually face consequences.
        grandempire 2y ago
        Now we are waiting for new legislation and overhaul of the tech system to make your point?
        pjmlp 2y ago
        Nah, it is already here depending on the country one lives on, I don't need to make any point. Also I stand by my comments even if they hurt feelings from people which probably never openened a single copy of ISO standards, not even the table of contents.
  - immibis 2y ago
    And then it was a decision on the part of compiler vendors to define it to do insane things like time travel. Not the standards committee. Compiler vendors could have just as well defined it to wrap.
    - jenadine 2y ago
      Some compiler decided to define overflow as wrapping. Such as GCC/clang when passing the -fwrapv flag. Most projects don't use that flag though, why not? Nite that if you assume -fwrapv, you're not writing in C anymore, you're using a vendor specific dialect.
      - immibis 2y ago
        Everyone writes in vendor-specific dialects of C. Both POSIX and Win32 define behaviour that isn't defined in C (such as rules for unaligned pointers), while also undefining behaviour that is defined in C (such as what happens if you call fopen when one of the functions in your program is called "open"). Even on embedded platforms, there's no "main" function in freestanding C - your entry point is a vendor-specific extension.
        eru 2y ago
        > Everyone writes in vendor-specific dialects of C. That's not true. Some people try to write fully spec compliant C programs that would behave the same on every compliant C compiler.
        immibis 2y ago
        Do they define functions called "open"?
    - eru 2y ago
      Time travel is a consequence of UB anywhere in an execution making the whole execution UB. The committee could have said that UB only makes the rest of the execution UB, not what happened before.
  - grandempire 2y ago
    Exactly. The classic example is invalid pointer deref. It’s too costly to check every deref against every allocation (outside of special debug modes). So the system usually can only detect if there is a virtual memory page fault, in which case it can crash. In embedded systems without virtual memory there is no validity checking at all. Or it could periodically check (random sampling). So the standard makes the reasonable choice to leave it undefined. If you can detect it and crash, that’s great. If not and you accidentally overwrite your programs instructions, anything can happen. Rust only avoids UB in so far as it relies on default clang behavior on modern hardware.
    - steveklabnik 2y ago
      Re Rust, that’s simply not true. Rust relies on compile time validity checks that have nothing to do with virtual memory.
      - grandempire 2y ago
        You confused two parts. I am not saying that Rust has the same pointer deref, I’m saying that if you try to specify rust you will find parts that implicitly rely on clang or hardware default. In other words the behavior is unspecified.
        steveklabnik 2y ago
        The borrow checker has a formal proof and it is completely independent from hardware.
        deleted 2y ago
        [deleted]
        grandempire 2y ago
        Gatorade gives you electrolytes.
    - jenadine 2y ago
  - wrs 2y ago
    You’re describing implementation-defined behavior, not undefined behavior. IB does something but the committee doesn’t say what. UB does anything and the compiler can assume you never intended to cause it.
  - eru 2y ago
    > It is the reason why the standard purposely leaves some areas undefined. No. It is _one_ of the reasons, not _the_ reason. For example, signed integer overflow. If all you were worried about was the behaviour of the underlying hardware, you would declare this _implementation defined_. (With the vast majority of implementations today picking twos-complement.) Instead, even compilers that target two-complement machines leave this deliberately undefined, so they can target exploit this corner for performance gains, without actually have to properly prove that leaving out certain checks would be sound under twos-complement.
pjmlp 2y ago
Security exploits is the problem, because what common people that don't read WG14 mailings think the word undefined means, and what everyone else involved with creating compilers understand what they are allowed to do, is not the same.
- motorest 2y ago
  > Security exploits is the problem, because what common people that don't read WG14 mailings think the word undefined means, and what everyone else involved with creating compilers understand what they are allowed to do, is not the same. Your comment lacks credibility. Your hypothetical scenario would only be conceivable if a) a team was well versed enough in C to adopt a specific toolchain to leverage implementetion-defined behavior that leveraged behavior left undefined by the C standard, b) somehow the same team decides on a whim to replace their toolset with some other random toolset without eve being aware of their toolset-specific code. This is far from a realistic scenario, and reads more like mindless complains about UB coming from a place of ignorance.
  - pjmlp 2y ago
    CVE database, the ongoing liability laws in cybersecurity across several nations, and companies that also happen to be C and C++ compiler vendors, are my credibility. It is incredible how for the last 50 years we keep getting ad-hominens from folks that think actually to know anything at all about security, and only clueless junior developers don't know what they are doing.

eru 2y ago

> [...] and the reason why some behavior is purposely left undefined in the standard? It's one of the saner reasons why there's UB in C and C++. But there's lots of crazier reasons.

motorest 2y ago
> It's one of the saner reasons why there's UB in C and C++. It is the reason why the standard purposely leaves some areas undefined. C and C++ detractors talk a lot about UB but they always show their understanding on the subject is at best superficial. The parrot UB as if it was this major gotcha, when it is literally behavior the standardization committees make a call to not define behavior to purposely leave it open, so that any implementation can still be conforming even if they decide to implement behavior not defined in the standard. It is that simple, but somehow people parrot UB behavior as if it was this major gotcha. Baffling.
- pjmlp 2y ago
  Baffling is the ignorance in the ways of WG14 and WG21, while pretending to be a know it all, maybe update yourself on the relevant papers for C2y and C++26, aimed at clearing up references to UB with erranous behaviour, or implementation defined.
  - formerly_proven 2y ago
    This subthread is kinda strange with people claiming IB and UB are the same, considering that C/C++ have had clearly delineated definitions of undefined behavior versus implementation-defined behavior for decades in their term definitions.
    - grandempire 2y ago
      No, we do understand the difference and the comment still stands. UB is a choice by the standard committee. Signed integer overflow is undefined because it’s not even clear if you can detect it happens in all implementations. Do you want a conditional after every integer add?
      - eru 2y ago
        > Signed integer overflow is undefined because it’s not even clear if you can detect it happens in all implementations. Do you want a conditional after every integer add? Huh? You can just make it implementation defined, and most implementations would declare it to work like twos-complement wrap-around. Just like unsigned integer overflow is already defined in the standard. Where does the conditional you are talking about come from? Unsigned integer overflow doesn't have any conditionals either. Compilers like GCC already support wrap-around for signed integers with a command line option. It's spelled "-fwrapv", and I don't think it involves any conditionals.
        grandempire 2y ago
        > You can just make it implementation defined No you can't. Let me repeat again. One very possible implementation is to crash on signed integer overflow (`-ftrapv`). But if it cannot easily detect it, then it must either: a) check every integer add. b) use some less reliable detection method (random sampling, etc). To be well defined means the implementation will reliably do the same thing. A procedure which sometimes does one thing or another, is not well defined. > Unsigned integer overflow doesn't have any conditionals either. That's because there is no detection needed. The instruction set for unsigned integers is designed to do that. > -fwrapv Here is the documentation: > This option instructs the compiler to assume that signed arithmetic overflow of addition, subtraction and multiplication wraps around using twos-complement representation. https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html What this means is that if your hardware wraps on signed integer overflow, you can tell GCC that you are perfectly happy with that behavior. Then GCC understands and will handle it just fine. If your hardware does something else, `fwrapv` will not help you.
  - grandempire 2y ago
    You are upset we aren’t familiar with papers and proposals which are not yet agreed on as standard? And for unreleased C++ versions?
    - jenadine 2y ago
      What's upsetting is comments that confidently state inaccurate or clearly wrong statements, thereby spreading misconceptions
      - motorest 2y ago
        > What's upsetting is comments that confidently state inaccurate or clearly wrong statements, thereby spreading misconceptions The bulk of the people in this thread clearly have no grasp of what UB is, even though they are very vocal in the way they parrot their misconceptions and outright absurdities. They would never write half the absurd and misguided claims they did if they were even aware the standards explicitly use the term "non-portable" to define UB.
    - pjmlp 2y ago
      Nah, thankfully liability legislation is finally happening so folks will actually bother to learn standards and how compilers approach them. Or eventually face consequences.
      - grandempire 2y ago
        Now we are waiting for new legislation and overhaul of the tech system to make your point?
        pjmlp 2y ago
        Nah, it is already here depending on the country one lives on, I don't need to make any point. Also I stand by my comments even if they hurt feelings from people which probably never openened a single copy of ISO standards, not even the table of contents.
- immibis 2y ago
  And then it was a decision on the part of compiler vendors to define it to do insane things like time travel. Not the standards committee. Compiler vendors could have just as well defined it to wrap.
  - jenadine 2y ago
    Some compiler decided to define overflow as wrapping. Such as GCC/clang when passing the -fwrapv flag. Most projects don't use that flag though, why not? Nite that if you assume -fwrapv, you're not writing in C anymore, you're using a vendor specific dialect.
    - immibis 2y ago
      Everyone writes in vendor-specific dialects of C. Both POSIX and Win32 define behaviour that isn't defined in C (such as rules for unaligned pointers), while also undefining behaviour that is defined in C (such as what happens if you call fopen when one of the functions in your program is called "open"). Even on embedded platforms, there's no "main" function in freestanding C - your entry point is a vendor-specific extension.
      - eru 2y ago
        > Everyone writes in vendor-specific dialects of C. That's not true. Some people try to write fully spec compliant C programs that would behave the same on every compliant C compiler.
        immibis 2y ago
        Do they define functions called "open"?
  - eru 2y ago
    Time travel is a consequence of UB anywhere in an execution making the whole execution UB. The committee could have said that UB only makes the rest of the execution UB, not what happened before.
- grandempire 2y ago
  Exactly. The classic example is invalid pointer deref. It’s too costly to check every deref against every allocation (outside of special debug modes). So the system usually can only detect if there is a virtual memory page fault, in which case it can crash. In embedded systems without virtual memory there is no validity checking at all. Or it could periodically check (random sampling). So the standard makes the reasonable choice to leave it undefined. If you can detect it and crash, that’s great. If not and you accidentally overwrite your programs instructions, anything can happen. Rust only avoids UB in so far as it relies on default clang behavior on modern hardware.
  - steveklabnik 2y ago
    Re Rust, that’s simply not true. Rust relies on compile time validity checks that have nothing to do with virtual memory.
    - grandempire 2y ago
      You confused two parts. I am not saying that Rust has the same pointer deref, I’m saying that if you try to specify rust you will find parts that implicitly rely on clang or hardware default. In other words the behavior is unspecified.
      - steveklabnik 2y ago
        The borrow checker has a formal proof and it is completely independent from hardware.
        deleted 2y ago
        [deleted]
        grandempire 2y ago
        Gatorade gives you electrolytes.
  - jenadine 2y ago
- wrs 2y ago
  You’re describing implementation-defined behavior, not undefined behavior. IB does something but the committee doesn’t say what. UB does anything and the compiler can assume you never intended to cause it.
- eru 2y ago
  > It is the reason why the standard purposely leaves some areas undefined. No. It is _one_ of the reasons, not _the_ reason. For example, signed integer overflow. If all you were worried about was the behaviour of the underlying hardware, you would declare this _implementation defined_. (With the vast majority of implementations today picking twos-complement.) Instead, even compilers that target two-complement machines leave this deliberately undefined, so they can target exploit this corner for performance gains, without actually have to properly prove that leaving out certain checks would be sound under twos-complement.

pjmlp 2y ago

Security exploits is the problem, because what common people that don't read WG14 mailings think the word undefined means, and what everyone else involved with creating compilers understand what they are allowed to do, is not the same.

motorest 2y ago
> Security exploits is the problem, because what common people that don't read WG14 mailings think the word undefined means, and what everyone else involved with creating compilers understand what they are allowed to do, is not the same. Your comment lacks credibility. Your hypothetical scenario would only be conceivable if a) a team was well versed enough in C to adopt a specific toolchain to leverage implementetion-defined behavior that leveraged behavior left undefined by the C standard, b) somehow the same team decides on a whim to replace their toolset with some other random toolset without eve being aware of their toolset-specific code. This is far from a realistic scenario, and reads more like mindless complains about UB coming from a place of ignorance.
- pjmlp 2y ago
  CVE database, the ongoing liability laws in cybersecurity across several nations, and companies that also happen to be C and C++ compiler vendors, are my credibility. It is incredible how for the last 50 years we keep getting ad-hominens from folks that think actually to know anything at all about security, and only clueless junior developers don't know what they are doing.