7 ms·

This is a myopic viewpoint. Undefined behavior is critical for code that needs to be fast. The premise of languages like C and C++ is that the airgap between th

This is a myopic viewpoint. Undefined behavior is critical for code that needs to be fast. The premise of languages like C and C++ is that the airgap between the language's abstract execution and memory model and the hardware's is thin to non-existent. *(edit accidentally submitted early) In this case, the UB is due to the compiler's ability to reorder statements. This is such a fundamental optimization that I can't imagine you're really suggesting that a language without this optimization capability is a "problem." Rearranging instructions is critical for pretty much any superscalar processor (which all the major ones are), and I hate to imagine the hell I'd be in if I had to figure out the optimal load/store ordering myself.

saagarjha 8y ago
> In this case, the UB is due to the compiler's ability to reorder statements. No, the undefined behavior arises because dividing by zero is undefined. Languages wishing avoiding this particular bug can make division by zero defined to trap or have some sort of guaranteed behavior, after which the compiler is required to not reorder those statements. In this case reordering the instructions is legal because having undefined behavior in your program makes literally anything the compiler does legal.
- banachtarski 8y ago
  My point still stands in that I don't want the compiler to check for division by zero if I don't ask it to.
  - saagarjha 8y ago
    Sure, then use C or C++ and check for it yourself. But if you mess up your program is invalid, so there's that. If you don't like that, write your own assembly by hand to convert this to implementation-defined behavior instead of undefined behavior.
  - deleted 8y ago
    [deleted]
kstenerud 8y ago
My point is that it is humanly impossible to write a bug-free program. In C and C++, bugs usually manifest themselves in UB. To make matters worse, compilers, ever searching for diminishing returns on performance improvements, have been steadily making the CONSEQUENCES of UB worse, to the point that even debugging is getting harder and harder. These languages are unique in their growing user hostility.
- llukas 8y ago
  > growing user hostility You have excellent tooling (*sanitizer, static analysis, valgrind, ${WHATEVER}) and abstractions provided to do handholding for you (ie. unique_ptr). Most of that was created in last few years.
  - pjmlp 8y ago
    Completely wrong. Lint was created in 1979, during the mid-90's we already had Insure++, Purify and others, ages before of the free beer alternatives. Yet being free still doesn't help the large majority of C and C++ to actually use them, as proven at one of CppCon talks, where a tiny 1% of the attendees confirmed using any kind of analysers.
    - minipci1321 8y ago
      How well the attendees of CppCon represent the developer base of C++ projects which are in dire needs of these tools? Maybe they are so skilled the need does not arise?
      - esrauch 8y ago
        Even people who work on the language spec can't really avoid writing code that hits UB without the help of sanitizers.
      - pjmlp 8y ago
        The amount of CVEs found per month on highly skilled projecs, with deep review processes, like the Linux kernel proove otherwise. As for how well, usually conferences like CppCon have the top of the tops.
pjmlp 8y ago
I was always able to write fast code in languages like Object Pascal and Ada, while being safe from C and C++ UB cargo cult.
- xmiller 8y ago
  But the authors of large, popular code bases chose C or C++. Anyone is free to rewrite Apache in Ada, but for some reason it isn't happening.
  - pjmlp 8y ago
    Ever heard of this little thing called money? Since free UNIX brought C into the masses, and Bjarne made C++ as a means to never have to touch bare C after his encounter with BCPL, many people have choosen this languages because they were a language with an OS SDK. So now unless we get some nice lawsuits, companies will keep picking the easy path.
    - jstimpfle 8y ago
      So, are you saying it's been difficult to get Ada or Free Pascal or Java up and running on a Unix system in the last 10 or 20 years?
      - pjmlp 8y ago
        What I am stating is that to re-write existing systems, regardless how rotten they might be, someone needs to pay for the work to happen. What many tend to forget on those "X re-written in Y" posts. Pay Per Hour * Total Hours Effort = Money Spent on Rewrite Additionally what I am saying is that languages that come with the OS SDK have first class privileges and experience shows that 99% of the companies won't look elsewhere. For example, in commercial UNIX days, you would get C and C++ compilers as part of the base SDK. The vendors that had support for additional languages like Ada, had them as additional modules. So any dev wanting to push for language X needed to make a case why the company needed to put extra money on the table instead of going with what they already got. A similar process happens on mobile and Web platforms nowadays, you either go with what is available out of the box or try to shoehorn an external toolchain and then deal with all integration issues and additional development costs ($$$) that might arise.
lmm 8y ago
> The premise of languages like C and C++ is that the airgap between the language's abstract execution and memory model and the hardware's is thin to non-existent. Which is not really the case for processors from the last 20+ years. > In this case, the UB is due to the compiler's ability to reorder statements. This is such a fundamental optimization that I can't imagine you're really suggesting that a language without this optimization capability is a "problem." Rearranging instructions is critical for pretty much any superscalar processor (which all the major ones are), and I hate to imagine the hell I'd be in if I had to figure out the optimal load/store ordering myself. UB is not necessary for that though. E.g. define that integer division by zero leads to the process receiving a terminal signal. That could be implemented just as efficiently (trapping on division by zero free at the hardware level in modern processors, the C standard gives broad freedom for signals to be received asynchronously so instructions could still be reordered), but would close the door to silent memory corruption and arbitrary code execution: unless the programmer has explicitly defined how the signal is handled, their program is noisily terminated.
- deleted 8y ago
  [deleted]

saagarjha 8y ago

> In this case, the UB is due to the compiler's ability to reorder statements. No, the undefined behavior arises because dividing by zero is undefined. Languages wishing avoiding this particular bug can make division by zero defined to trap or have some sort of guaranteed behavior, after which the compiler is required to not reorder those statements. In this case reordering the instructions is legal because having undefined behavior in your program makes literally anything the compiler does legal.

banachtarski 8y ago
My point still stands in that I don't want the compiler to check for division by zero if I don't ask it to.
- saagarjha 8y ago
  Sure, then use C or C++ and check for it yourself. But if you mess up your program is invalid, so there's that. If you don't like that, write your own assembly by hand to convert this to implementation-defined behavior instead of undefined behavior.
- deleted 8y ago
  [deleted]

kstenerud 8y ago

My point is that it is humanly impossible to write a bug-free program. In C and C++, bugs usually manifest themselves in UB. To make matters worse, compilers, ever searching for diminishing returns on performance improvements, have been steadily making the CONSEQUENCES of UB worse, to the point that even debugging is getting harder and harder. These languages are unique in their growing user hostility.

llukas 8y ago
> growing user hostility You have excellent tooling (*sanitizer, static analysis, valgrind, ${WHATEVER}) and abstractions provided to do handholding for you (ie. unique_ptr). Most of that was created in last few years.
- pjmlp 8y ago
  Completely wrong. Lint was created in 1979, during the mid-90's we already had Insure++, Purify and others, ages before of the free beer alternatives. Yet being free still doesn't help the large majority of C and C++ to actually use them, as proven at one of CppCon talks, where a tiny 1% of the attendees confirmed using any kind of analysers.
  - minipci1321 8y ago
    How well the attendees of CppCon represent the developer base of C++ projects which are in dire needs of these tools? Maybe they are so skilled the need does not arise?
    - esrauch 8y ago
      Even people who work on the language spec can't really avoid writing code that hits UB without the help of sanitizers.
    - pjmlp 8y ago
      The amount of CVEs found per month on highly skilled projecs, with deep review processes, like the Linux kernel proove otherwise. As for how well, usually conferences like CppCon have the top of the tops.

pjmlp 8y ago

I was always able to write fast code in languages like Object Pascal and Ada, while being safe from C and C++ UB cargo cult.

xmiller 8y ago
But the authors of large, popular code bases chose C or C++. Anyone is free to rewrite Apache in Ada, but for some reason it isn't happening.
- pjmlp 8y ago
  Ever heard of this little thing called money? Since free UNIX brought C into the masses, and Bjarne made C++ as a means to never have to touch bare C after his encounter with BCPL, many people have choosen this languages because they were a language with an OS SDK. So now unless we get some nice lawsuits, companies will keep picking the easy path.
  - jstimpfle 8y ago
    So, are you saying it's been difficult to get Ada or Free Pascal or Java up and running on a Unix system in the last 10 or 20 years?
    - pjmlp 8y ago
      What I am stating is that to re-write existing systems, regardless how rotten they might be, someone needs to pay for the work to happen. What many tend to forget on those "X re-written in Y" posts. Pay Per Hour * Total Hours Effort = Money Spent on Rewrite Additionally what I am saying is that languages that come with the OS SDK have first class privileges and experience shows that 99% of the companies won't look elsewhere. For example, in commercial UNIX days, you would get C and C++ compilers as part of the base SDK. The vendors that had support for additional languages like Ada, had them as additional modules. So any dev wanting to push for language X needed to make a case why the company needed to put extra money on the table instead of going with what they already got. A similar process happens on mobile and Web platforms nowadays, you either go with what is available out of the box or try to shoehorn an external toolchain and then deal with all integration issues and additional development costs ($$$) that might arise.

lmm 8y ago

> The premise of languages like C and C++ is that the airgap between the language's abstract execution and memory model and the hardware's is thin to non-existent. Which is not really the case for processors from the last 20+ years. > In this case, the UB is due to the compiler's ability to reorder statements. This is such a fundamental optimization that I can't imagine you're really suggesting that a language without this optimization capability is a "problem." Rearranging instructions is critical for pretty much any superscalar processor (which all the major ones are), and I hate to imagine the hell I'd be in if I had to figure out the optimal load/store ordering myself. UB is not necessary for that though. E.g. define that integer division by zero leads to the process receiving a terminal signal. That could be implemented just as efficiently (trapping on division by zero free at the hardware level in modern processors, the C standard gives broad freedom for signals to be received asynchronously so instructions could still be reordered), but would close the door to silent memory corruption and arbitrary code execution: unless the programmer has explicitly defined how the signal is handled, their program is noisily terminated.

deleted 8y ago
[deleted]