from Hacker News

Schrödinger's Code

by wheresvic4 on 7/12/21, 11:31 PM with 16 comments

• by Sniffnoy on 7/13/21, 5:32 AM

  > A different philosophy reigns in domains that demand efficiency and speed (e.g., infrastructure software). Systems programming languages such as C and C++ sacrifice safety and comprehensive semantics for performance. These languages, despite being meticulously standardized, do not define the behavior of all code that compiles.

  This is really just a problem with C and C++, though, not systems programming in general. Obviously those are the most popular languages for it, but that's something of an accident; it's not due to their use of undefined behavior. If anything their use of undefined behavior may be beginning to drive people away, and famously the Linux kernel uses special compiler settings to turn off some such optimizations.

  Moreover, as already noted by hwayne in another comment, undefined behavior was originally primarily for compatibility purposes; compilers didn't begin exploiting it for (expected-semantics-destroying) speedups until much later.

  So, I think it is a mistake to frame the dispute in this way, identifying systems programming with being pro-undefined-behavior. It seems to me that the "school of thought" (not actually a school of thought) that says that behavior should be predictable from source encompasses most systems programmers too.

• by hwayne on 7/13/21, 2:10 AM

  One important piece of historical context this article doesn't talk about: a lot of the undefined behavior in C is there for compatibility, not for optimization. C came out in 1972 while the first official C standard is from 1989. The standard had to be backwards-compatible with all of the major compilers, which had almost 20 years to diverge. That's the source of a lot of undefined and implementation-defined behavior.

• by userbinator on 7/13/21, 3:38 AM

  Such rants have not achieved the desired effect. On the contrary, compiler writers have given notice that they will continue exploiting the liberties granted by the language standards.

  That suggests to me that the opposition to this exploitation needs to be even stronger...

  To take this whole discussion in a philosophical direction, I see the two sides of the argument as having a real-world analogy to laws vs. morals and ethics. The current attitude popular amongst compiler writers is that of strict legality; the term "language-lawyering" certainly applies. But like the real-life analogy, what is legal is not necessarily moral or ethical, and vice-versa. There's a lot of discussion on other topics, here and elsewhere, where that idea is highly debated --- someone will post something along the lines of "but what they're doing is legal", and then many replies will elaborate why that is still wrong.

  Yet for some reason, when C and UB comes up, for some reason it seems not agreeing with those ruthlessly exploiting the standard and belittling everyone who dares question them is a highly unpopular and controversial opinion?

• by justshowpost on 7/13/21, 7:40 AM

  That's the reason one should ALWAYS attend to warnings and even treat them as errors eg. by fixing them

• by woliveirajr on 7/13/21, 1:12 PM

  Nasal demons, as always [0].

  [0] http://catb.org/jargon/html/N/nasal-demons.html

• by IlliOnato on 7/13/21, 2:47 PM

  Is this really a problem with "infrastructure languages", or just C and C++? Are other "infrastructure languages" plagued by UB? What about D, C#? What about languages which are not "C inspired"?

• by philipswood on 7/13/21, 5:05 AM

  This simplifies to: Maybe avoid using C completely and be very careful if you have to.