Should C language "undefined behaviour" cover crashing/hanging?

[Sherlock Holmes]

Yes, there is, but this is not what C specification says. And compilers implement the specification. So, your complaint is to the standards people, not the compiler writers.

I suppose you're right. I guess that's what happens when you try to mould a standard around a lot of existing and varied implementation.


Don't get me wrong, I'm not criticising the C language as a whole. If I were upset about this stuff, I wouldn't be using it. I know it's the programmer's job to avoid triggering undefined behaviour (e.g. check your divisor values first, your array bounds, that pointers are valid, etc.). I just wish in some areas (like this) there was more predictability and consistency. Speaking of which, further to my example above, I just remembered one more thing about this scenario: the routine for 32-bit division (as opposed to modulus) doesn't even have the same issue! It uses a different algorithm and is perfectly fine with a divisor of zero! Even more inconsistency.

I think the whole thing about "undefined behaviour" meaning any random event could occur - up to and including your computer exploding, your hair turning purple, or being haunted by evil spirits - needs to have some kind, pragmatic consideration applied. Not for compiler or library writers to just shrug their shoulders and say "we're okay with letting random shit happen even though some of it is under our control".

Edit: That last sentence also gave rise to this thought: as I understand it, a lot of C undefined behaviour is due to having to allow for the idiosyncrasies of varied hardware. The circumstances that lead to undefined behaviour may be uncontrollable due to the nature of the platform code is running on. But when the behaviour is entirely within an entity's control (e.g. add a line of code to a library routine to perform a zero check), I think that is when pretence of "we can't help it" needs to go away.

Well it is undefined, their docs make that clear. One could argue - hypothetically - that division by zero is a known no-no, so what is it in the algorithms of the system that cause the denominator to get set to zero? get into an invalid state? If the software is deterministic then the invalid state must be seen as a bug of some kind with some explanation, somewhere there is an assignment to memory that sets that number to zero or it is uninitialized.

Of course with exception support life is a lot easier.


 

[cfbsoftware]

I fully agree. And I don't like that UB exists. But I can hardly blame people in 1972 for not thinking about it.

I can blame them. The relevant knowledge was available at that time.

[hamster_nz]

I fully agree. And I don't like that UB exists. But I can hardly blame people in 1972 for not thinking about it.

I can blame them. The relevant knowledge was available at that time.

I am sure they did think about it. Hardware back then was far less 'generic' in capability and implementation. Even how many bits were in a character or byte was still up in the air. This is over a decade before IEEE floating point was a thing.

C was designed around what is the minimum reasonable behavior we can expect from a computer. C also says "don't play outside that safe space if you want consistent, portable, predictable results from your code".

[SiliconWizard]

I fully agree. And I don't like that UB exists. But I can hardly blame people in 1972 for not thinking about it.

I can blame them. The relevant knowledge was available at that time.

I am sure they did think about it. Hardware back then was far less 'generic' in capability and implementation. Even how many bits were in a character or byte was still up in the air. This is over a decade before IEEE floating point was a thing.

C was designed around what is the minimum reasonable behavior we can expect from a computer. C also says "don't play outside that safe space if you want consistent, portable, predictable results from your code".

Yes, yes and yes.
No UB almost always guarantees more overhead for the compiled code, and/or stringent constraints on the supported targets. Neither is a fit for C.
I will even venture that had C not had any UB cases, it would have been long dead by now.

[Siwastaja]

I will even venture that had C not had any UB cases, it would have been long dead by now.

Yes - C is practical, like many of us engineers. And I truly enjoy seeing how the practicality of C and the massive success thereof triggers so many "computer scientist" types of people who can't stand something so practical just works against their expectations, and refuses to die or get replaced against their predictions, decade after decade. I'm not as much as C fanboy, but more like a "C hatred discussion enjoyer".

[tggzzz]

I will even venture that had C not had any UB cases, it would have been long dead by now.

Yes - C is practical, like many of us engineers. And I truly enjoy seeing how the practicality of C and the massive success thereof triggers so many "computer scientist" types of people who can't stand something so practical just works against their expectations, and refuses to die or get replaced against their predictions, decade after decade. I'm not as much as C fanboy, but more like a "C hatred discussion enjoyer".

As a practicing electronics and software engineer, I too like practical tools and products.

One principal characteristic of a practical tool is that it is predictable and without surprises. Those characteristics are the principal reason HP became a great instrumentation company: their products just worked as you would expect them to work. "Nobody was ever fired for buying HP"

K&R C satisfied those characteristics. OK, you had to read both books about C, but together they were about 2cm thick.

Modern C fails to have those characteristics. That's due to the increased complexity of the underlying hardware, and C's attempts to be both "low-level-close-to-Si" and "general-high-level-applications" languages.

My preference would be for C to be only low-level close-to-the-silicon, and to have left applications to other languages. In any case, the community is voting against C for the latter in favour of Java, Rust, and other simpler and more practical (for general purpose applications) languages.

So, in trying to be all things to all people, C stopped being ideal for its important niche.

[Mechatrommer]

nobody mentioned the fix/workaround? C++ Exceptions try and catch? well ok, its C++, we only want C right?... so <errno.h> well, still not quite it... then why you dont build your own "C Library" (the stripped down one if you like) with whatever your heart content behaviour you like once the "undefined behaviour" is encountered? or why you are not capable of doing a rigorous unit testing?

btw imho, entering a infinite loop after an undefined behaviour is an ill behaviour, even though specification approved it. imagine a rocket launched that relies on the software for trajectory calculation, with undetected bug before the launch.. what happen when the software goes infinite loop? it will just do nothing except wasting mcu energy doing infinite loop. and what chance the rocket can survive or recover when the software halted? if program continues (ignores) after an undefined is triggered, at least there is non-zero chance that it will recover (by luck), or by itself or the nature of the code that will reset all values once new sensors data are retreived...





imho undefined behaviour should provide exit or re entry/reboot vector to the software, at the very least basic level is C++ style catch all exceptions, if its too hard to do, your custom library should callback to one generic function act as exception handler for all... or you analyze for any possible singularities, or better, do rigorous unit testing. if you dont know how to do that given any language thrown at you, or the one you choosed, please dont accept a tender offer relating to life critical project, if you dont have senior and experienced colleague programmer that has very clear solution in mind about how to take care of that... you may just want to generate your code from Google AI.

or, repeating this (to back me up?)...

Undefined behavior covers anything including the destruction of the machine (look up halt and catch fire).

If you don't want this to happen, then it's your job as C programmer to make sure you never trigger this behavior, for example by checking a divisor is non-zero before dividing. Undefined in the C spec equivalent of your doctor saying "If you get a headache after drinking five cups of coffee, then don't drink five cups of coffee".

If you want the language to take care of this instead of you, use a higher level language that defines a zero division exception or something like that.

i wish i can type more but this new SMF forum "quoting system" is f*king annoying. a proof that newer program is not always better, given a "not so thoughtfull" person behind programming it.

[Sherlock Holmes]

As I and many others have said before, the C language was never really designed, certainly not in the formal manner we expect to see when an amplifier is designed or a jet engine or radio receiver. So its silly to expect it to behave like it was designed, if you want predictable behavior under unanticipated circumstances, then I'm sorry but that requires work, effort, creativity AKA design, and C ain't it.

C was a hack job, a quick and dirty "it'll do for now" because designing was too much effort, it wasn't intended to be a serious, practical language, just something crude but useable to play with operating system ideas.

It became popular while still little more than a prototype, a proof of concept, and once inertia got behind it any prospect of real design or a serious review and restatement of goals became impossible.

There could have been a C version 2.0 project that tidied up loose ends, incorporated exception handling, improved the grammar and so on, that could have been willing to break backward compatibility in order to do things right. But it never happened and to this day many developers wax lyrical, expressing affection for what is a kludge.

C is very valuable because we can learn from it, mistakes are hugely valuable for this reason, one must make mistakes to make true progress, but valuing mistakes doesn't mean we should wallow in them, admire them and defend them.

[DiTBho]

Old IBM mainframe mime, look up halt and catch fire.
Today is "disable channels.and halt".

[Mechatrommer]

C was a hack job, a quick and dirty "it'll do for now" because designing was too much effort, it wasn't intended to be a serious, practical language, just something crude but useable to play with operating system ideas.

says who? says someone who collecting questionaires about machine and ARM language in this forum in this few days? or says someone better than Bell's Lab computer scientist who got a Turing Award? working for years on it? and Unix, from where Linux was originated? https://en.wikipedia.org/wiki/C_(programming_language)

[Sherlock Holmes]

C was a hack job, a quick and dirty "it'll do for now" because designing was too much effort, it wasn't intended to be a serious, practical language, just something crude but useable to play with operating system ideas.

says who? says someone who collecting questionaires about machine and ARM language in this forum in this few days? or says someone better than Bell's Lab computer scientist who got a Turing Award? working for years on it? and Unix, from where Linux was originated? https://en.wikipedia.org/wiki/C_(programming_language)

Don't rant about me the person, prove me wrong, if you have evidence I'm wrong then present it and we can discuss the matter without animosity or insults or insinuations of incompetence.

Trying to argue against me on the basis of presumed credentials or lack thereof won't strengthen your case, besides I've designed and developed compilers far more sophisticated than C, have you? still want to talk credentials?

[Mechatrommer]

C was a hack job, a quick and dirty "it'll do for now" because designing was too much effort, it wasn't intended to be a serious, practical language, just something crude but useable to play with operating system ideas.

says who? says someone who collecting questionaires about machine and ARM language in this forum in this few days? or says someone better than Bell's Lab computer scientist who got a Turing Award? working for years on it? and Unix, from where Linux was originated? https://en.wikipedia.org/wiki/C_(programming_language)

Don't rant about me the person, prove me wrong, if you have evidence I'm wrong then present it and we can discuss the matter without animosity or insults or insinuations of incompetence.

Trying to argue against me on the basis of presumed credentials or lack thereof won't strengthen your case, besides I've designed and developed compilers far more sophisticated than C, have you? still want to talk credentials?

did you click and read the link? and the links inside? where is your credentials or proofs? you can talk to yourself that when you make a wild statement, please also provide your proofs to show you are right.

[MK14]

As regards the title/topic of this thread.  The point is, C is suppose to be (as I understand it), a systems language.

Consider, a hypothetical Make Character Uppercase, type of function.  Which might boil down to just being a logical OR or AND, of the appropriate byte, with the correct binary immediate value, to accomplish the task.

If you do it with a single OR or AND instruction (as necessary, depending on if UPPER or LOWER case needed, etc).  It can perhaps take 1/7th of an instruction cycle to execute (assuming typically 7 instructions are executed in the same cycle, by the superscaler processor and its out of order unit).

But, if it is insisted that the language performs extensive safety checks, at run time, even at the lowest (system) level.  It might need to check the address is within the valid bounds of the particular array (if applicable).  It might check the value is NOT 0 (NULL), as that may indicate a possible error somewhere.
It could check the value is not less than 32, and is not too big, etc.
Possibly other safety checks could be implemented.

But then with all the extra memory accesses, comparisons, branches and other stuff.  It might take 5 or even 20 or more times longer to execute.

So, if all those safety checks are applied to nearly all operations, even at such a fundamentally low level.  The language will end up producing stuff, which takes, perhaps twenty times longer to run, compared to if it could just ignore all those safety checks.

So, if GCC (mostly written in C) takes 10 minutes, to currently compile all your files, for a particular project, it would then end up taking, perhaps 200 minutes, instead (assuming the GCC time, was mostly due to CPU performance).

Similarly, most other things (which end up being written in C), would also take (perhaps) twenty times longer.

Such a situation, would tend to reduce peoples interest in C, and maybe make another language, be rather popular, because of its execution speed.

Some of the safety checks (in general), could be done at compile time, without affecting run time performance.  In which case, they could be useful, as long as the compile times, don't end up becoming too long, as a result.

In other words, in practice.  It is often necessary to choose between a very safe/robust language, that tends to protect users and programmers, against some kinds of mistakes/errors, but is perhaps not the fastest of languages, and language(s), that give the ultimate performance, that a computer can give.

[mfro]

If you can't live with occasional snags, don't use a scalpel. Scalpels are for professionals only.

If you can't live with C's UB concept, don't use C. C is a sharp blade as well.

[Sherlock Holmes]

C was a hack job, a quick and dirty "it'll do for now" because designing was too much effort, it wasn't intended to be a serious, practical language, just something crude but useable to play with operating system ideas.

says who? says someone who collecting questionaires about machine and ARM language in this forum in this few days? or says someone better than Bell's Lab computer scientist who got a Turing Award? working for years on it? and Unix, from where Linux was originated? https://en.wikipedia.org/wiki/C_(programming_language)

Don't rant about me the person, prove me wrong, if you have evidence I'm wrong then present it and we can discuss the matter without animosity or insults or insinuations of incompetence.

Trying to argue against me on the basis of presumed credentials or lack thereof won't strengthen your case, besides I've designed and developed compilers far more sophisticated than C, have you? still want to talk credentials?

did you click and read the link? and the links inside? where is your credentials or proofs? you can talk to yourself that when you make a wild statement, please also provide your proofs to show you are right.

I'm very familiar with C and that Wikipedia article, why did you want me to look at it? But, consider this, from that article:

Thompson desired a programming language to make utilities for the new platform. At first, he tried to make a Fortran compiler, but soon gave up the idea.

These guys borrowed a few ideas from PL/I like pointers, include files, preprocessing (which they did very poorly in C), but they didn't have the compiler design experience to build a PL/I compiler or even a Fortran compiler. There's nothing wrong with that, with what they did, but they did not aspire to exploit some of the latest ideas in programming language design.

They ignored exception handling, superbly supported (in fact first introduced) in PL/I, the gave up on the preprocessor, again an idea that was at the time at its pinnacle in PL/I (do some reading on PL/I's preprocessor!). They abandoned strings and bit data types.

Writing an OS and having no exception handling support in the language is not an encouraging design decision, a divide by zero or something, in kernel mode code, could crash the OS. The Multics team fully appreciated that and is why they adopted PL/I, the first language to support exceptions (called "conditions" in PL/I parlance).

Remember exceptions is an inherent characteristic of CPUs, its a "hardware feature" so if C was "designed to be close to the hardware" it would have incorporated exception handling wouldn't it?

So if C had been truly designed, let alone designed for writing an OS, it would not have ignored these recent cutting edge programming language ideas.

[Mechatrommer]

if you call evolution, improvement, expansion is a hack, then everything is a hack including python and what you are going to (re) invent... C evolved, you dont expect whats work today will work 10-20 years from now. and its not the first language Ritchie experimented. please know your place... unless if you already have something better (credentials) to prove, ie once your language got on top list for decades....

If you can't live with C's UB concept, don't use C. C is a sharp blade as well.

yes use C sharp (C#)

[Sherlock Holmes]

if you call evolution, improvement, expansion is a hack, then everything is a hack including python and what you are going to (re) invent... C evolved, you dont expect whats work today will work 10-20 years from now. and its not the first language Ritchie experimented. please know your place... unless if you already have something better (credentials) to prove, ie once your language got on top list for decades....

Yes "hack" is normal when being creative, I agree with you. But creativity is also about the human mind imposing order and consistency and symmetry on things, so its cyclic, hack/review, hack/review, good design doesn't stop at the hack stage, but at the review and reorganization following lessons learned etc.

I'm also not arguing that C is not ubiquitous (I avoid describing it as "popular"). It is ubiquitous, that's not automatically a good thing either, guns are ubiquitous in the US, nothing good about that.

[tggzzz]

If you can't live with occasional snags, don't use a scalpel. Scalpels are for professionals only.

If you can't live with C's UB concept, don't use C. C is a sharp blade as well.

The problem is that very few programmers understand all the subtle and surprising causes of "undefined behaviour". Most think they do, of course That was famously illustrated when Hans Boehm thought it worthwhile to write a paper pointing out that you couldn't write a threading library in C - too many people presumed or "thought" you could.

C++ is worse. The committee defining the language didn't understand what they had created until their noses were rubbed in it by a short program that spat out the sequence of prime numbers while it ws being compiled. That's right; the design committee hadn't realised C++ templates are a Turing complete language in themselves - and that some valid C++ programs could never finish being compiled.

The least unsatisfactory alternative with C is to adhere to one of the relatively benign subsets of C, e.g.  MISRA.

[Sherlock Holmes]

If you can't live with occasional snags, don't use a scalpel. Scalpels are for professionals only.

If you can't live with C's UB concept, don't use C. C is a sharp blade as well.

The problem is that very few programmers understand all the subtle and surprising causes of "undefined behaviour". Most think they do, of course That was famously illustrated when Hans Boehm thought it worthwhile to write a paper pointing out that you couldn't write a threading library in C - too many people presumed or "thought" you could.

C++ is worse. The committee defining the language didn't understand what they had created until their noses were rubbed in it by a short program that spat out the sequence of prime numbers while it ws being compiled. That's right; the design committee hadn't realised C++ templates are a Turing complete language in themselves - and that some valid C++ programs could never finish being compiled.

The least unsatisfactory alternative with C is to adhere to one of the relatively benign subsets of C, e.g.  MISRA.

That's interesting, such subtleties are often far from obvious. I made a PL/I compiler crash in the past, in PL/I you can declare a variable as "based on" some pointer. That it, the pointer used to get at the variable is stated in the declaration, in the code just access the variable by name, without explicit use of a pointer.

Anyway, these declarations can crash some compilers:

Code: [Select]


dcl a_ptr pointer based (b_ptr);
dcl b_ptr pointer based (a_ptr);


I "fixed" this in my own compiler by counting how many steps are taken during the resolution of a variable's address, if it's > 100 say, we stop and report a recursively declared variable, it did the trick (I admit this was a true "hack") and its pretty unlikely real code would ever chain declarations to that degree.

[MK14]

If you can't live with occasional snags, don't use a scalpel. Scalpels are for professionals only.

If you can't live with C's UB concept, don't use C. C is a sharp blade as well.

The problem is that very few programmers understand all the subtle and surprising causes of "undefined behaviour". Most think they do, of course That was famously illustrated when Hans Boehm thought it worthwhile to write a paper pointing out that you couldn't write a threading library in C - too many people presumed or "thought" you could.

C++ is worse. The committee defining the language didn't understand what they had created until their noses were rubbed in it by a short program that spat out the sequence of prime numbers while it ws being compiled. That's right; the design committee hadn't realised C++ templates are a Turing complete language in themselves - and that some valid C++ programs could never finish being compiled.

The least unsatisfactory alternative with C is to adhere to one of the relatively benign subsets of C, e.g.  MISRA.

If you cover the scalpel, with cotton wool, safety tape and other precautions, making it so that even a toddler, could use it safely.

What do you think would happen to a patient, that urgently needs an operation to save their life, if the only tool available, was the aforementioned, scalpel?

If a tricky embedded system, needs to perform a very rapid software operation, in order to work, safely and correctly, otherwise, the voltage/system/etc will change too much (in real-time), ruining the motor controller, or whatever the system/software is trying to do.

Then your suggested 'new' language, i.e. NOT very high speed/efficient C, may make the task relatively unsolvable with the existing/affordable hardware.

In other words.  Use the RIGHT TOOL for the RIGHT JOB.  Not some film-flamcy cotton wool, safety tape covered, thing, that is not suitable for doing the job in hand.

[Siwastaja]

What do you think would happen to a patient, that urgently needs an operation to save their life, if the only tool available, was the aforementioned, scalpel?

If a tricky embedded system, needs to perform a very rapid software operation, in order to work, safely and correctly, otherwise, the voltage/system/etc will change too much (in real-time), ruining the motor controller, or whatever the system/software is trying to do.

Then your suggested 'new' language, i.e. NOT very high speed/efficient C, may make the task relatively unsolvable with the existing/affordable hardware.

In other words.  Use the RIGHT TOOL for the RIGHT JOB.  Not some film-flamcy cotton wool, safety tape covered, thing, that is not suitable for doing the job in hand.

To be fair, C has some footguns, uncertainties and unsafety that are not required to get the power. It is just that people who find C unusably bad, tend to come up with much worse alternatives that fail to provide the "power" as you point out.

C is like a scalpel which fits in the hand relatively well, but not perfectly, and sometimes it slips. Most "C hateboys" are those who ask for a language where scalpel is wrapped in cotton wool, or a scalpel that looks like a beautiful cathedral. But the right thing to ask for is a scalpel which is still a scalpel, but a few safety improvements. Think about a knife with that "bump" in the handle which prevents your hand from slipping into the blade if you push it down. C lacks this "bump". But C has a rigid screw hole in the right place so you can easily add this bump.

I do admit it is interesting to discuss about the crappiness of C, but the end result seems to be: it's still not colossally too bad, and alternatives do not prove very usable, so - we stick with C, and we are careful, and we make far fewer mistakes than the "C is dangerous" alarmists claim. At least for myself, 95% of my bugs are in logical thinking and would happen in any language. Maybe some 5% would be avoidable with a better designed language. I don't even remember when I last time overindexed a table or made a mistake with a zero-terminated string, it has been years!

[Sherlock Holmes]

If you can't live with occasional snags, don't use a scalpel. Scalpels are for professionals only.

If you can't live with C's UB concept, don't use C. C is a sharp blade as well.

The problem is that very few programmers understand all the subtle and surprising causes of "undefined behaviour". Most think they do, of course That was famously illustrated when Hans Boehm thought it worthwhile to write a paper pointing out that you couldn't write a threading library in C - too many people presumed or "thought" you could.

C++ is worse. The committee defining the language didn't understand what they had created until their noses were rubbed in it by a short program that spat out the sequence of prime numbers while it ws being compiled. That's right; the design committee hadn't realised C++ templates are a Turing complete language in themselves - and that some valid C++ programs could never finish being compiled.

The least unsatisfactory alternative with C is to adhere to one of the relatively benign subsets of C, e.g.  MISRA.

If you cover the scalpel, with cotton wool, safety tape and other precautions, making it so that even a toddler, could use it safely.

What do you think would happen to a patient, that urgently needs an operation to save their life, if the only tool available, was the aforementioned, scalpel?

If a tricky embedded system, needs to perform a very rapid software operation, in order to work, safely and correctly, otherwise, the voltage/system/etc will change too much (in real-time), ruining the motor controller, or whatever the system/software is trying to do.

Then your suggested 'new' language, i.e. NOT very high speed/efficient C, may make the task relatively unsolvable with the existing/affordable hardware.

In other words.  Use the RIGHT TOOL for the RIGHT JOB.  Not some film-flamcy cotton wool, safety tape covered, thing, that is not suitable for doing the job in hand.

The danger with analogies is that even a slightly misleading one can lead to conclusions that aren't true for the original scenario. We can compare C to a broken chainsaw, or a broken semi automatic, nobody would advocate a surgeon use a broken scalpel, or a scalpel with a chipped, loose, blunt blade would they?

[Sherlock Holmes]

What do you think would happen to a patient, that urgently needs an operation to save their life, if the only tool available, was the aforementioned, scalpel?

If a tricky embedded system, needs to perform a very rapid software operation, in order to work, safely and correctly, otherwise, the voltage/system/etc will change too much (in real-time), ruining the motor controller, or whatever the system/software is trying to do.

Then your suggested 'new' language, i.e. NOT very high speed/efficient C, may make the task relatively unsolvable with the existing/affordable hardware.

In other words.  Use the RIGHT TOOL for the RIGHT JOB.  Not some film-flamcy cotton wool, safety tape covered, thing, that is not suitable for doing the job in hand.

To be fair, C has some footguns, uncertainties and unsafety that are not required to get the power. It is just that people who find C unusably bad, tend to come up with much worse alternatives that fail to provide the "power" as you point out.

C is like a scalpel which fits in the hand relatively well, but not perfectly, and sometimes it slips. Most "C hateboys" are those who ask for a language where scalpel is wrapped in cotton wool, or a scalpel that looks like a beautiful cathedral. But the right thing to ask for is a scalpel which is still a scalpel, but a few safety improvements. Think about a knife with that "bump" in the handle which prevents your hand from slipping into the blade if you push it down. C lacks this "bump". But C has a rigid screw hole in the right place so you can easily add this bump.

I do admit it is interesting to discuss about the crappiness of C, but the end result seems to be: it's still not colossally too bad, and alternatives do not prove very usable, so - we stick with C, and we are careful, and we make far fewer mistakes than the "C is dangerous" alarmists claim. At least for myself, 95% of my bugs are in logical thinking and would happen in any language. Maybe some 5% would be avoidable with a better designed language. I don't even remember when I last time overindexed a table or made a mistake with a zero-terminated string, it has been years!

Well I can argue that the committed C devotees, can only ever defend their position by making up analogies! Defending the language on technical, engineering, computational prowess or expressive merits is just too hard to do.

[Marco]

What do you think would happen to a patient, that urgently needs an operation to save their life, if the only tool available, was the aforementioned, scalpel?

I think it's more like tablesaws with saw stops and without, lots of professional wood workers will keep becoming 9 digit professionals for the foreseeable future but times are a changing.

C programmers got their chance with Cyclone C, now bean counters will make the choice and it will not be C-like. Learn to love Rust and Ada-SPARK, though I admit they are hard to love.

[MK14]

I think it's more like tablesaws with saw stops and without, lots of professional wood workers will keep becoming 9 digit professionals for the foreseeable future but times are a changing.

C programmers got their chance with Cyclone C, now bean counters will make the choice and it will not be C-like. Learn to love Rust and Ada-SPARK, though I admit they are hard to love.

That's a good counter analogy.  As CPUs become ever increasingly fast, powerful and relatively low cost (for the performance you get).  The importance of compiler language's speed efficiency, gradually diminish, over the years.

I'd prefer if a particular language, had programmer adjustable options, which could vary the amount of safety checking, a compiler does, especially during run-time.  Then during some parts of code production and/or testing/debugging, a high safety checking mode/status could be selected.
But for eventual production releases (non-safety-critical ones), those various safety checks could be disabled.
But if it was especially important and/or safety-critical and/or doesn't need high efficiency compilation.  The safety checks could be left enabled.

Some languages, already include such features, such as Lazarus/FreePascal, Borland (various name changes, later) Pascal/Delphi, and so on.  With things like forced array bounds checking and overflow, checks being enabled or disabled, at will, inside the compiler/linker configurations.