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

[Mechatrommer]

Part of the popularity is of course non-technical, as always

"printf" was/is a good example here, in this forum 
(we tried to get rid of it, but ...)

make your own! just dont make another confusing/non-compliance standard such as printf2 or ditbho_printf, unless for your own..

[mfro]

The Ada-SPARK / ADA type languages, seem to need (I've not really looked into it, especially hard), the purchase, of presumably expensive compiler licenses.  Which, compared to the wide range of apparently free interpreters and compilers available, such as GCC.  Is difficult to stomach.

GNAT (GNU Ada) comes at the exact same cost as any other GNU compiler: zero. It passes 100% of ACATS (kind of an Ada standards compliance test).

[MK14]

The Ada-SPARK / ADA type languages, seem to need (I've not really looked into it, especially hard), the purchase, of presumably expensive compiler licenses.  Which, compared to the wide range of apparently free interpreters and compilers available, such as GCC.  Is difficult to stomach.

GNAT (GNU Ada) comes at the exact same cost as any other GNU compiler: zero. It passes 100% of ACATS (kind of an Ada standards compliance test).

Thanks, that is interesting to know.   

I think because I (previously), only had a rather/very quick scan of Ada (There are so many millions of different, new/upcoming programming languages these days), it is difficult to keep up.
I mainly looked at the commercial Ada site.  Which claimed so many tempting features, for the paid compiler.  It put me off, from taking the free GNU Ada compiler seriously, after that point.

But obviously, that company (who sell the Ada compiler), have a special interest, in claiming their paid for compiler, is THE compiler to get.

I vaguely remember there was some feature I really wanted which the paid compiler had, but the free one didn't.  But my recollection is too weak to remember exactly.

EDIT:
Tried to find it, and I think it was this:
https://www.adacore.com/about-ada

I wanted one or more of the 'new' Ada 2012 features in that big feature matrix.  But rightly or wrongly, had decided the free (GNU etc) compilers, didn't support it (Ada 2012), so I wouldn't get the desired feature(s).

Since the price is marked 'Request pricing'.  I assumed, it wasn't set to a price, that would attract hobby project budget compilers.

I.e. If something says 'Request Pricing' as an option, rather than specifying the actual price.  I assume, the price is going to be (silly) expensive and/or these days, not only a huge amount of money, but also, needs renewing, every 12 months.

[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.

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.

I have not suggested another language, except the xC+xCORE exosystem which guarantees timing in a way no other ecosystem does. A 4000MIPS processor isn't slow

The right tool for the kind of job you mention is emphatically not C.

Candidates might include Ada or subsets such as MISRA C or SPARK Ada.

[tggzzz]

From the compiler point of view unsafe Rust and Ada pragma'd to turn off runtime checks can express pretty much the same thing as equivalent C, it's the programmers which will get slower converting to Ada-SPARK and especially Rust.

The Ada-SPARK / ADA type languages, seem to need (I've not really looked into it, especially hard), the purchase, of presumably expensive compiler licenses.  Which, compared to the wide range of apparently free interpreters and compilers available, such as GCC.  Is difficult to stomach.

I.e. If we go back to the old days, when most compilers had to be paid for.  It wasn't so much of a problem, as you could choose the language you wanted, then buy it (if affordable).

But nowadays, with so much free stuff to choose between.  It is difficult to justify paying, just to use a particular language.  Perhaps for a hobby project.
I think there is an old (not up to modern standards), open source, free version of ADA, floating about.  But if I remember correctly, it seemed too old and using outdated language specifications, to try out.

If compilers should be free or not, I suppose is another topic of conversation.

In a professional context, the cost of a compiler is irrelevant. That cost is dwarfed by other NRE costs: just consider the cost of a failure in the field, or the costs associated with specification, design, implementation, debugging and integration with other systems. There are other non-technical costs as well, of course.

In an amateur context, the cost of a compiler is dominant.

I'm confused as to whether you are considering amateur or professional devices.

[MK14]

I'm confused as to whether you are considering amateur or professional devices.

In that context, Hobby/fun use.  A new, hopefully robust language to play with, and maybe do some stuff with.

I agree.  If it involves a workplace/business, the cost is often irrelevant.  Unless it is very significantly overpriced.  Which some people think Altium PCB is.

[Siwastaja]

I could go on, but there's no point, you could accept at least some of these as valid criticisms rather than stubbornly defending the language no matter what I say.

You misinterpret others because you are not paying attention, and because we are making it worse by making fun of your blindness.

Everyone agrees with (nearly) all points in that list of criticisms. There are good counter-points to many of those (more like explanations why it is so, not that it makes it any better), but not all, some are just objectively very stupid, such as the messed-up double use of keyword static.

It's just we have heard all of this thousands of times, we all know about it, and we agree with it.

So what's next? We want to hear constructive ideas how it could be done better. You got a pretty bad start with your thread because your mixed bag of random ideas, some just poorly though out syntactic sugar which does not taste any better than the "static" mess in C, just different, some having consequences in memory footprint making your language not suitable for small microcontrollers, contrary to the thread title, and so on and so on. Combined with an extremely overconfident "I know this stuff and you don't" attitude. A bad mix; assholes like me are tolerated when we are at least right or have good ideas 95% of the time.

So instead of repeating the "C is crap" ad nauseam, which we alreardy know, try something new. Or don't, finally it doesn't matter.

[Marco]

"printf" was/is a good example here, in this forum 
(we tried to get rid of it, but ...)

Printf has also been a big cause of exploits BTW. But I can't really blame that purely on C, it's as much because of bad design ideas put in stone during the Unix era regardless of C. Combining escape sequences with un-trusted text input is an atrociously bad idea. By now it's so entrenched, people can't even conceive of alternatives.

[Sherlock Holmes]

I could go on, but there's no point, you could accept at least some of these as valid criticisms rather than stubbornly defending the language no matter what I say.

You misinterpret others because you are not paying attention, and because we are making it worse by making fun of your blindness.

Everyone agrees with (nearly) all points in that list of criticisms. There are good counter-points to many of those (more like explanations why it is so, not that it makes it any better), but not all, some are just objectively very stupid, such as the messed-up double use of keyword static.

It's just we have heard all of this thousands of times, we all know about it, and we agree with it.

So what's next? We want to hear constructive ideas how it could be done better. You got a pretty bad start with your thread because your mixed bag of random ideas, some just poorly though out syntactic sugar which does not taste any better than the "static" mess in C, just different, some having consequences in memory footprint making your language not suitable for small microcontrollers, contrary to the thread title, and so on and so on. Combined with an extremely overconfident "I know this stuff and you don't" attitude. A bad mix; assholes like me are tolerated when we are at least right or have good ideas 95% of the time.

So instead of repeating the "C is crap" ad nauseam, which we alreardy know, try something new. Or don't, finally it doesn't matter.

We think you are the one being repetitive, you've expressed nothing but cynicism to the suggestion that a new language could be designed, suggested nothing you'd like to see in a new language. I asked what people would like to see in a new language, you've not shared any of the kinds of features you'd find helpful or valuable, We've been asking and you and one or two others have repeatedly done little more than dismiss the idea altogether, express contempt for such an idea.

You ask "I want to hear constructive ideas" yet ignore the very posts that contained some of the possible areas one could look at, e.g.

There are several things that a new language would bring, here's a summary of the more salient:

• No reserved words, thus enabling new keywords to be added over time.
• Support 'bit' as a native data type.
• Support 'strings' as a native type, BCD/decimal as well.
• Support for namespaces.
• Computed gotos.
• Flexible alignment, packing and padding directives.
• Nested functions.
• Precision timing features like emit multiple NOP operations or ensure identical execution time for (say) case clauses in a switch.
• Support for an async/await model.

These are the kinds of things that I've seen other people raise or complain about sometimes, things that a freshly designed language could readily accomodate.

and

At a minimum the language would include:

1. More storage classes than C (defined, based etc)
2. More data types including decimal/BCD and strings of fixed or variable length.
3. Arbitrary rank arrays with optional bound specifiers.
4. Distinguish between function and procedures.
5. Fine control over padding and alignment and field ordering etc.
6. No object oriented features, no GC, no virtual functions and so on.
7. No need for "forward declarations"
8. Nested functions/procedures.
9. Some kind of "computed" goto support.
10. No reserved words.
11. No explicit pointer arithmetic, like ptr++ and ptr-- and so on.
12. Invocable variables (a simpler form of C's function pointer)

That's the basic initial list anyway, entirely reasonable and feasible and something I've implemented successfully in the past.

I also looked into the possible design of coroutine support and literals that allow space as separators for binary, octal, hex and decimal and nested procedures and an initialization operator for any kind of type or aggregate data structure, and Unicode UTF-8 support and the possibility of having a keyword dictionaries for different languages like French, Spanish, German and so on, but nothing from you, not a peep just endless complaining about the fact someone dares to broach the subject with you.

So why do you say "I want to hear constructive ideas" when you pretty obviously do not, actions speak louder than words and so far you've made no meaningful suggestions or contributions to the discussion.

Please do not presume to describe me as over confident either, that's another of your regular insulting remarks, do not try project your own inadequacies onto others please.

[MK14]

I don't think you should be posting big chunks of stuff from a DIFFERENT thread, and discussing it in this one.
Best to keep the discussion to that other 17+? page thread.

Because it will just cause too much confusion, and damage/destroy/off-topic this thread, which somewhat belongs to someone else and/or this forum.

[Sherlock Holmes]

I don't think you should be posting big chunks of stuff from a DIFFERENT thread, and discussing it in this one.
Best to keep the discussion to that other 17+? page thread.

Because it will just cause too much confusion, and damage/destroy/off-topic this thread, which somewhat belongs to someone else and/or this forum.

I think you are right, I will do that, my post was a reaction to Siwastaja's post above though, he brought that thread up and I simply wanted to counter his unfounded claims.

[SiliconWizard]

"printf" was/is a good example here, in this forum 
(we tried to get rid of it, but ...)

Printf has also been a big cause of exploits BTW.

Yep. Now, as I just said in another thread, exploits are often more due to lack of proper input validation than on the function itself.

Think prevention vs. protection. But it's always easier to blame one's tools.

But I can't really blame that purely on C, it's as much because of bad design ideas put in stone during the Unix era regardless of C. Combining escape sequences with un-trusted text input is an atrociously bad idea. By now it's so entrenched, people can't even conceive of alternatives.

It's a relatively bad idea given how it can go bad in so many ways, but I can understand the appeal. Formatted printing is convenient to use. Re-read the thread about printf() alternatives, many people don't want to have to deal with alternatives that require more programming effort. A format string is easy to use and (relatively) easy to read, and while much more elaborate ways of implementing them in a safer way are possible, that was certainly out of the question back in the early 70's.

But anyway - you just pinpointed the issue, as I said above.

VALIDATE YOUR INPUTS.

[DiTBho]

it's the same with php: sanitize your fields -> validate your inputs

[hamster_nz]

I would love to hear Sherlock Holmes's thoughts on PASCAL. It was around at about the same time as C in the early adoption of PCs, and a far more 'designed' language. "Turbo Pascal" and "Turbo C" were approximately equal languages at tools, and I've used both.

Why did PASCAL not win, given its technical superiority?

[SiliconWizard]

It has largely survived though, mainly through Delphi (which despite what people may think, still has a large user base. It's just a much more silent crowd. Maybe because the stuff just works.)

[Marco]

It's a relatively bad idea given how it can go bad in so many ways, but I can understand the appeal. Formatted printing is convenient to use. Re-read the thread about printf() alternatives, many people don't want to have to deal with alternatives that require more programming effort. A format string is easy to use and (relatively) easy to read

The format string should be a constant string literal or only allow formatting (with text passed in as %s arguments) and returning an error on any other text in the format string.

[Mechatrommer]

"printf" was/is a good example here, in this forum 
(we tried to get rid of it, but ...)

Printf has also been a big cause of exploits BTW.

Yep. Now, as I just said in another thread, exploits are often more due to lack of proper input validation than on the function itself.

Think prevention vs. protection. But it's always easier to blame one's tools.

But I can't really blame that purely on C, it's as much because of bad design ideas put in stone during the Unix era regardless of C. Combining escape sequences with un-trusted text input is an atrociously bad idea. By now it's so entrenched, people can't even conceive of alternatives.

It's a relatively bad idea given how it can go bad in so many ways, but I can understand the appeal. Formatted printing is convenient to use. Re-read the thread about printf() alternatives, many people don't want to have to deal with alternatives that require more programming effort. A format string is easy to use and (relatively) easy to read, and while much more elaborate ways of implementing them in a safer way are possible, that was certainly out of the question back in the early 70's.

But anyway - you just pinpointed the issue, as I said above.

VALIDATE YOUR INPUTS.

c is not about safety nor protection to your heart content. Its just 'minimally works' i mean its standard library.. if anyone not happy with it, make another safe library on your own, dont use the standard printf, as the OP has figured out.. but then there's people on enterprise grade who want everything ready on silver platter safe and sound, regardless of what holy excuses you give them.. so its futile.. hows the NSA and CIA deals with SW things? What alternative? Visual Basic has been around for ages and pretty much covers everything mentioned here, about boundary check and safety exceptions.. its the most charming human friendly syntax, options to do safety boundary check, vs optimize for speed code during compilation etc etc, but it never went as popular and long lived as C, everybody went to bloated java or python. Siwastaja possibly explained it. Nothing technical, just support ecosystem, marketing, about the right timing or even money laundering whatever that made a language go, even if its crappier than the earlier.

[Mechatrommer]

I would love to hear Sherlock Holmes's thoughts on PASCAL. It was around at about the same time as C in the early adoption of PCs, and a far more 'designed' language. "Turbo Pascal" and "Turbo C" were approximately equal languages at tools, and I've used both.

Why did PASCAL not win, given its technical superiority?

i got the chance to try out Borland C++ Builder, Borland Delphi (GUI version using Pascal) and MSVStudio... those are were expensive and highly regarded IDE tools... i ditched the former 2 and stick with MSVS (C++ Studio and VB)  just because i cant get them to work with my own diy custom dll/api... MSVS solved pretty much everything mentioned/suggested/proposed in every threads in this forum since ages.. so.. 

[Sherlock Holmes]

I would love to hear Sherlock Holmes's thoughts on PASCAL. It was around at about the same time as C in the early adoption of PCs, and a far more 'designed' language. "Turbo Pascal" and "Turbo C" were approximately equal languages at tools, and I've used both.

Why did PASCAL not win, given its technical superiority?

My understanding is pretty much the same as this, I think this explanation fits the facts.

https://qr.ae/pvcWaV

First almost always beats best. Look at the crippled Intel CPU used in the IBM PC, the 68000 was head and shoulders above Intel, yet by comparison became like Pascal. Intel's crippled CPU was simply ready earlier, the rest is history.

[Sherlock Holmes]

Here's an extremely thought provoking blog post about languages, particularly about the cause of memory corruption, is it the language or the programmer...

I loved this:

The P0 spin on this myth is: if you’ve made a bug, make sure you don’t make another bug when you fix the first bug.

That would be nice, but, really? Programmers are supposed to take their usual process, which produced the bug in the first place, and turn on INFALLIBLE MODE so that there is no bug in the patch? How likely is that?

[SiliconWizard]

Here's an extremely thought provoking blog post about languages, particularly about the cause of memory corruption, is it the language or the programmer...

I loved this:

The P0 spin on this myth is: if you’ve made a bug, make sure you don’t make another bug when you fix the first bug.

That would be nice, but, really? Programmers are supposed to take their usual process, which produced the bug in the first place, and turn on INFALLIBLE MODE so that there is no bug in the patch? How likely is that?

I don't really see the thought provoking factor here. He pretty much says what almost everyone else does. How is that provoking anything?

[hamster_nz]

I would love to hear Sherlock Holmes's thoughts on PASCAL. It was around at about the same time as C in the early adoption of PCs, and a far more 'designed' language. "Turbo Pascal" and "Turbo C" were approximately equal languages at tools, and I've used both.

Why did PASCAL not win, given its technical superiority?

My understanding is pretty much the same as this, I think this explanation fits the facts.

https://qr.ae/pvcWaV

First almost always beats best. Look at the crippled Intel CPU used in the IBM PC, the 68000 was head and shoulders above Intel, yet by comparison became like Pascal. Intel's crippled CPU was simply ready earlier, the rest is history.

Gosh, that very much differs from my recollection. Here's mine:

PASCAL predated C by a few years and was also commonly available. I remember using it on an Apple II and it was often seen in the press (e.g. Byte Magazine, Dr Dobbs, books at the bookstore...). It took over as the preferred language for introductory CompSci at University (until it got pushed out by Java in the late 90s). Its syntax was also used as the bases for most academic pseudocode you find in books of that era.

What killed Pascal was:

• Early versions of Pascal didn't compile to native code. It ended up in a 'p-code' ( https://en.wikipedia.org/wiki/P-code_machine ) . This was great for portability, but poor for performance. You could not extract the full power of the machine - if you needed to you used something else. It valued portability above performance
• it wasn't flexible enough. Pascal had a runtime model that was very hard to get rid of, making writing system level code very challenging. With C you pretty much abandon the runtime library and do your own thing. This made Pascal unsuited to writing low-level code like building OSes.
• Code performance. When the first advanced optimizing C compilers came out PASCAL got left behind in performance. C's crudeness made for intermediate code that was easier to analyze and optimize in the resource constrained environments of the time. You ended up with smaller, faster code when you used C.
• Pascal users would still need to use assembly for performance critical code. C would let you replace most of your assembly code with something that could be more easily developed and maintained. It was not at all uncommon for Pascal users to link to modules written in C code for performance reasons - much like how Python used now interface to C when needed. Most developers were of the view that if you are going to invest time implementing your critical code in C, you may as well use it for the rest of your codebase.

This was all at a time where business applications were largely written in something else - either in COBOL or one of the many 4GL development tools like DBase, FoxPro, DataFlex, Magix, Pick, etc. Almost nobody was writing business applications in C.

[SiliconWizard]

Yup.

But Turbo Pascal, especially the later versions, solved most of these issues. By the latest versions, it had become a very capable language with a lot more going for it than C, like units (which were Pascal modules), a clean programming model, etc. But at this point it was too late for two main reasons IMO: first, C had become king on Unix-like system AND Windows (C was still the primary dev language on Windows until the late 90's), then C++ took over, and later Java for application programming.

Yep, C was king for Windows app development for most of the 90's. Remember the famous Petzold books. C++ on Windows only really started taking over in the second half of the 90's.

And Pascal still had this "academic" image linked to it. But the interesting part is that it has survived, not only in all the languages it inspired, but also as Delphi/Object Pascal which is still used.

Anyway, it's all history, but as always, popularity often has very little to do with technical merits.

[berke]

People don't realize how much of a technological achievement Rust is.  Previously that kind of type safety, strength and expressivity was only available in garbage collected languages such as OCaml or Haskell where directly playing with hardware is a huge pain.  Now it's available with no runtime overhead.

In a C world, if you have to call third-party code, that code can corrupt memory (or registers) in a subtle way undetectable to all the Valgrinds of the world, and you'll spend two months looking for a bug that appeared to be in your code but was some weird memory management race condition in the third party library that was corrupting a few bits in your code.

In Rust you can safely call third-party code.  If they assure you they don't use unsafe Rust, you automatically know that your code will not crash because of their code.  If it does, it's a rare compiler fault or a hardware issue.  It's not going to crash as in segmentation fault to begin with.  If it's buggy it's not going to corrupt memory in unpredictable ways.  The whole language has been designed from the ground-up to prevent that.  The compiler checks all the code, all the branches, all the cases, with one hundred percent coverage.

This also means you can hire junior devs (or foreign spies) and they're not going to make your software unstable, at least in ways unrelated to your business logic.

The main drawback is that you're gonna have a bad time if your code has allocated structures with pointers all over the place.  That's not something that can be automatically proven memory-safe.  (That's what the Rust compiler does, it literally automatically and mathematically proves that your code is memory safe, or gives you a counter-example.)  So you'll have to wrap everything within reference-counted, mutex'ed pointers and that's painful.  For code like that, use a GC'd language.

Another drawback is that the compiler and standard library codebase (including LLVM) is ginormous, you need gigabytes to compile something and it's CPU intensive (but so is C++).  A decent C compiler takes very little memory.

But You can use Rust to produce code for small devices, but not on small devices.

Speaking of which you can also write low-level embedded code in Rust (check out the embedded-hal crate), but of course you'll have to write some unsafe code to encapsulate ISRs or other hardware accesses.  Those parts can be written by the more experienced developers and provided as safe functions for the interns to use without crashing the system.

[Sherlock Holmes]

Here's an extremely thought provoking blog post about languages, particularly about the cause of memory corruption, is it the language or the programmer...

I loved this:

The P0 spin on this myth is: if you’ve made a bug, make sure you don’t make another bug when you fix the first bug.

That would be nice, but, really? Programmers are supposed to take their usual process, which produced the bug in the first place, and turn on INFALLIBLE MODE so that there is no bug in the patch? How likely is that?

I don't really see the thought provoking factor here. He pretty much says what almost everyone else does. How is that provoking anything?

Well it just provoked a response from you didn't it, I presume you think before you respond, in which case you have your answer.