> when everyone was coding assembly..

This was before my time, but I think it's a common misconception (only true for operating system development). When C was created, there was already Lisp, Cobol, Fortran, Algol, Simula, BASIC... and SmallTalk and Prolog were just around the corner - and most of those are much higher level than C).

I think parent knows. A more accurate description would be everyone of the intended audience was writing assembly. Yes there are other languages of higher levels, but C was not invented to help their users. And since they are also not really what Rust targets either, IMO it’s reasonable to shorten it to drop the qualifier in this context.

> since they are also not really what Rust targets either

Exactly this. This belief that Rust can and even will replace C is at best ignorant and at worst evangelical. In fact I’m convinced most Rust enthusiasts on HN are less involved in programming and more with politics.

While I’m all for mem-safe languages Rust is simply too abstract and undefined to work on any real embedded systems work. At most, it can work on the driver level, but even that code will need to be constantly redone as the language ages without any proper specifications.

C was invented in the context of porting UNIX, while the world outside Bell Labs used something else, that is all there is to it.

Sure, but none of those were for systems programming which is squarely the domain that C was aimed at, case in point: the first thing that C was used to write was UNIX (before then it was BCPL and this was iirc before C even had structs which made that a very tricky job, once structs were in place it got a lot easier). Probably Don Hopkins has more knowledge about this.

> before C even had structs which made that a very tricky job...

...interesting that you mention that, I think that functions and structs are the essential 'core abstraction tools' that get you to at least 80% of any higher level abstractions that were invented since then, and this is exactly the reason why C is still quite popular. Its feature set is just enough to be considered a high level language which enables abstractions, but not more (especially no fads and fashions that came and disappeared again).

C23 has lots of stuff into it, except improved safety.

There were enough languages for systems programming outside Bell Labs, all the way back to 1958.

It is a urban myth that C was the first one, usually pushed by naturally UNIX folks.

JOVIAL, ESPOL, NEWP, PL/I, PL/S, PL.8, PL/M, Bliss, Mesa, Modula-2, VMS Basic, VMS Pascal,...

> C gives you enough rope to shoot yourself in the foot.

If this was intended to illustrate the unexpected consequences of undefined behavior it succeeded remarkably well!

Undefined Behaviour was a very late 'addition' to C, it only became necessary when C was standardised around 1990. And only after two more decades passed, UB became an actual problem when compiler vendors decided that it's fine to exploit it for optimization tricks.

Did you miss their point? They merely used UB, correctly, as a term we all do recognize today.

I will utterly kill all humor by explaining it:

They made a funny observation about a thing that happens. The thing that happens is (today) called UB. The funny observation is that that comment kind of exhibited the outward appearance of what the effects of UB could look like.

It began reciting one metaphore, "enough rope to hang yourself" but mid-way unexpectedly switched to a different metaphore "shoot yourself in the foot", producing a combined invalid nonsensical output. As though a program suffered some UB in the routine for looking up and printing metaphores.

The comment author might have done it on purpose. Maybe they intended to make exactly that joke.

The history of the term UB has no more bearing than the history of any of the other words used.

“Decided that it’s fine to exploit it for optimisation tricks” is a poor characterisation. The reality is, if you define particular behaviours you will harm performance in some cases. If you define how something in particular should happen, then all architectures will need to implement that, regardless of their underlying semantics.

eg. C leaves the case of exceeding the size of an int undefined. In most cases it has a predictable effect on modern, mostly similar architectures but that is by no means guaranteed, and forcing an architecture to calculate overflow a particular way seems like a negative.

That being said, everyone has a pet example of a compiler doing some really odd and deep optimisations - I suspect that’s mostly due to successive layers and optimisers adding up to have unexpected effects, rather than a deliberate effort by compiler writers - but I’m no expert on the matter.

> UB became an actual problem when compiler vendors decided that it's fine to exploit it for optimization tricks.

Section 4. Conformance says "A strictly conforming program shall only use those features of the language and library specified in this International Standard. It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any implementation limit."

Compilers are not allowed to produce output dependent on UB for strictly conforming ISO C programs, they must optimize those statements out. Treating UB as impossible is required for ISO C. It's NOT required for GNU C, or Clang C, or Microsoft Visual C, but they usually do so anyway (even though they're not compiling strictly conforming ISO C programs).

>It came out in a time when everyone was coding assembly

Expect to hear from @pjmlp on this!