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

[Siwastaja]

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.

You miss the fact that we do engineering, based on technical facts, day in day out. These discussions are free-time for us, and making up analogies is fun.

Also the technical sides have been pretty much covered already, over and over again.

Besides, whenever we go deep into technical, factual reasoning, nothing seems to be enough for you because you want "proof" instead of "opinions". So enjoy actual opinions, and some stupid analogies. It's more fun, anyway.

[Siwastaja]

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.

Many of the things people want from C, are actually available as compiler extensions already, and as a practicalist, that is completely fine to me, and I don't feel bad still calling it "C". GCC can add runtime checks for out of bound array access, and also check UB, as ataradov already showed on post #13: https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Instrumentation-Options.html

But these threads always go in circles because people enjoy the discussion itself and do not spend a lot of time in reading and digesting what was said and what the consequences are thereof.

[MK14]

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!

I think a significant part of the C languages success, has been that it has reached a sort of 'critical mass'.  It has sort of become one of the main languages, for a number of reasons:

• People working on it, know that there is lots of information/books about it, many places where questions can be asked about it, and a huge base of programmers in it, past and present, who can potentially help
• Employers/Businesses like it.  Because they know projects written in C, can have extra C programmers added to the job.  As and when needed, even if those needs are not properly understood at the moment.  Whereas a new, upcoming language.  May lack programmers who are experienced in it, books on it, other information sources, and may become relatively extinct/unpopular, in perhaps 5 or 10 years time
• C is very likely to be available for a long time to come.  So future support, is rather likely
• C is the 'safe pair of hands', choice
• There are decent C compilers, available for a bewilderingly big range of different archetectures
• C is continually/gradually changing/evolving to hopefully meet upcoming future needs, in a controlled way.  Reasonably free of political (Goverment) or Specific Business, involvement.  E.g. Some other languages, are closely tied to particular companies, that may chnage the language for the wrong reasons
• There is a very big, wide range of pre-existing libraries, to do an amazing range of things, available out there.  Both free ones and paid ones
• The various Linux's (and similar) operating systems, along with the software which goes with it (on the OS release version and its repositories).  Is often written in C (or C++), which tends to keep C and its compilers on the straight and narrow.
  Because if it (C) drifted too far from normality, it would fail to be able to successfully compile an entire Linux distribution, along with the various repositories, that are also available
• C is treated as a standard.  So other new/upcoming languages, know that if they support some of the C syntax.  There will be many programmers already familiar with it

In some respects, it (C) is a bit like Windows.  People use it (critical mass), because it has become so common-place and well used, that to NOT use it, would be a major headache, and potentially badly affect future sales of a software product.

I.e. The item in question (E.g. Windows), is NOT necessarily that good/brilliant, these days.  But has become so common-place, that, that fact alone, is enough to sort of force it on people.

E.g. I'm not necessarily a big fan of windows, and perhaps try to avoid it.  But some things, such as some particular types of software and/or hardware.  Can be difficult or very tricky to use, without using windows.
Such as a new FPGA kit, which ONLY comes with windows drivers to write to the FPGA development board, and its development software, ONLY runs on windows, and can't be made to run on a windows emulated environment (wine), in Linux.

[Sherlock Holmes]

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.

You miss the fact that we do engineering, based on technical facts, day in day out. These discussions are free-time for us, and making up analogies is fun.

Also the technical sides have been pretty much covered already, over and over again.

Besides, whenever we go deep into technical, factual reasoning, nothing seems to be enough for you because you want "proof" instead of "opinions". So enjoy actual opinions, and some stupid analogies. It's more fun, anyway.

Alright, that's fine with me, analogies it is! So if the C language was implemented in hardware, it would look a lot like this:



You can see all of the many vendor extensions there quite well, the support of different standards here and there too, pretty much captures all of the bells and whistles I think.

[MK14]

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?

That is true.  But powerful analogies and metaphors, can be useful techniques, for rapidly getting points across, to many people, reasonably quickly.

Fire, fire, get the heck out of here, else get burnt to a crisp.

Gets to the point much quicker, than saying something like:

I hope you don't mind me pointing this out.  But there is a tiny little bit of smouldering going on here.  Which in time, might get worse. Etc ...................

The low level features of C, are sort of like, having a mini-assembly like language, built into C.  So, the potential dangers, of such features.  Are arguably no worse, than real assembly language.  Which will usually blindly do whatever you ask of it, however crazy/mistaken the program accidentally/unintentionally becomes.

[Siwastaja]

No, I think you accidentally posted C++ (just the standard without compiler extensions).

C with compiler extensions is attached.

[Sherlock Holmes]

No, I think you accidentally posted C++ (just the standard without compiler extensions).

C with compiler extensions is attached.

Ahh, you're right, my apologies, here we go, if the C language was clothing:

[Mechatrommer]

Alright, that's fine with me, analogies it is! So if the C language was implemented in hardware, it would look a lot like this:



You can see all of the many vendor extensions there quite well, the support of different standards here and there too, pretty much captures all of the bells and whistles I think.

i dont get your analogy... what different vendor extensions? what different standards? and what are you suggesting as better alternative? i will looking forward to look up vendor extensions and different standards on the better language you are suggesting.

[MK14]

Many of the things people want from C, are actually available as compiler extensions already, and as a practicalist, that is completely fine to me, and I don't feel bad still calling it "C". GCC can add runtime checks for out of bound array access, and also check UB, as ataradov already showed on post #13: https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Instrumentation-Options.html

But these threads always go in circles because people enjoy the discussion itself and do not spend a lot of time in reading and digesting what was said and what the consequences are thereof.

I see.  I hadn't notice (or had forgotten) that post you refer to (#13).  Thanks, that is a GOOD post, to know about!

Those flag settings, look useful in some circumstances.  Some of those options (not the ones you mentioned), are only available on some architectures and/or can't work in combination with some other flag settings.

Those 'going round in circles', is perhaps partly because we don't (yet at least), have a post scoring mechanism and/or post highlighting and/or best/voted/favorite post, moved to top and highlighted, feature.  In the forum software.  But Dave seemed to mention/ask about it recently.

The downside of course, would be that it would annoy some people, whose post(s) didn't get chosen/upvoted and the timeline of thread/post development, would be lost and potentially more confusing than it is, now.

Also, sometimes the favorite post chosen by the OP, is the one they like, but is NOT the technically best/correct answer really.  Just the one, that apparently agrees, with the OPs, pre-existing technical misunderstandings.

E.g. An expert recommends only changing the fuse to an equivalent/identical one, of no higher current rating.
Whereas the chosen by OP as best answer post, is by some random person, who basically described using a nail as a short-circuit device.  Just because it is much cheaper, easier, and doesn't involve buying the correct fiddly fuse(s).
Despite the answer being somewhat crazy, potentially highly dangerous, and unsafe advise.

[Siwastaja]

Ahh, you're right, my apologies, here we go, if the C language was clothing:

Isn't that the opposite? I mean, C lets you do pretty much what you want, including unsafe things. The clothing pictured would be when a C greybeard becomes mentally unstable and is given Ada to work with to do less harm, no?

[Mechatrommer]

Those 'going round in circles'

i think because one group want everything if possible readily served on silver plater, ie the built-in library, the compiler, and the (managed) language is doing the job for them, the boundary check, UB's behaviour etc. i guess thats what the profession demands for production's sake. this goes me extrapolating that what they actually wish for is a language/compiler that can read their mind or at least program a simple line DoMyProgram() and everything is done. and the other old school group (probably for hobby sake like me) still want to stick with all manual control bare down to the metal language who happily do if ((i >= size) || (divisor == 0)) CallBackUndefineBehaviour(); or diy build a bulletproof memory management class/library for a particular resource limited HW, i think this is what OP tried to do and solve halfly and then encountered problem in built-in/standard library, which library vendor/maker? i'm not sure but i dont recall an infinite loop on my M$ C/C++ compiler during my entire life programming, it just throw exception and program exited. lets hope we extinct and lets see what the new generation/language can offer in the future, better or worse? without C... Google AI possibly that is...

[Sherlock Holmes]

Alright, that's fine with me, analogies it is! So if the C language was implemented in hardware, it would look a lot like this:



You can see all of the many vendor extensions there quite well, the support of different standards here and there too, pretty much captures all of the bells and whistles I think.

i dont get your analogy... what different vendor extensions? what different standards? and what are you suggesting as better alternative? i will looking forward to look up vendor extensions and different standards on the better language you are suggesting.

Arm C Language Extensions

Microsoft extensions to C

Nvidia C Language extensions

Microchip C Language extensions

Ahh, the old "what are you suggesting as better alternative" defense, how predictable.

[Sherlock Holmes]

Ahh, you're right, my apologies, here we go, if the C language was clothing:

Isn't that the opposite? I mean, C lets you do pretty much what you want, including unsafe things. The clothing pictured would be when a C greybeard becomes mentally unstable and is given Ada to work with to do less harm, no?

Well a straitjacket lets you do what you want too, so long as you don't want to do anything it won't let you do, so no, it's an excellent analogy!

[MK14]

Those 'going round in circles'

i think because one group want everything if possible readily served on silver plater, ie the built-in library, the compiler, and the (managed) language is doing the job for them, the boundary check, UB's behaviour etc. i guess thats what the profession demands for production's sake. this goes me extrapolating that what they actually wish for is a language/compiler that can read their mind or at least program a simple line DoMyProgram() and everything is done. and the other old school group (probably for hobby sake like me) still want to stick with all manual control bare down to the metal language who happily do if (i >= size) CallBackUndefineBehaviour(); or diy build a bulletproof memory management class/library for a particular resource limited HW. lets hope we extinct and lets see what the new generation/language can offer in the future, better or worse? without C...

I think, what some of the others, might want or be describing, is like an aircraft's autopilot.  But one, which doesn't have any way of switching it off or disabling it.  Which is fine and dandy, until a computer instruments failure mean you're about to crash into a giant mountain or the ground, and because the auto-pilot is always enabled/on.  There is no way for the pilots, to change the path of the aircraft, to avoid the mountain.

If anyone thinks my example is wrong.  Please look into the Boeing 737 MAX accidents.  Which involved control systems (MCAS), which the pilots couldn't disable/control (with the knowledge those particular pilots had, at the time), with disastrous results. 

[Mechatrommer]

i dont get your analogy... what different vendor extensions? what different standards? and what are you suggesting as better alternative? i will looking forward to look up vendor extensions and different standards on the better language you are suggesting.

Arm C Language Extensions

Microsoft extensions to C

Nvidia C Language extensions

Microchip C Language extensions

Ahh, the old "what are you suggesting as better alternative" defense, how predictable.

you doing sort of informal fallacy on C. just because its so extensible by nature, which is imho is a big plus, so every vendors is doing extension to it in their own way, i also made my own extended library complete with bulletproof boundary check classes, so that made me the 15th standards which is bad? (but luckily i dont publish, its for my own). what do you expect? M$ style of driver certification where each vendor should comply to certain standards set by the committee? and possibly pay for the certification? M$ got heavy bashing for this, no? how could you satisfy all? are you going to make a language that only you you can extend it? good luck! python faced the same compatibility issue! on ever expanding library/extensions

[DiTBho]

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.

That's exactly how I managed to "solve" my problems 

20x the code size you would get with C89 and 20x slower (-O1 is the only one implemented at the moment).
As a benefit it simplifies both ICE-testing and ICE-coverage.

[Siwastaja]

you doing sort of informal fallacy on C. just because its so extensible by nature

No, that's not the fallacy of Mr. Holmes. The fallacy is that some other languages having less extensions (or idea level toy projects not needing extensions at all) prove something more than just their unpopularity.

C language is not specially "extensible" by nature. All languages are. Usual compiler extensions as showed by Holmes do not use any "extension" system built in C. They just ... are.

But every other language is the same! You totally can come up with your own Ada or Rust or Java or C# or Python compiler which accepts exactly your own command line options, deviates from the standard just as you like, or even adds keywords if you so wish. Just ... do it!

The real reason why C gets so many extensions is the popularity and wide-spread use of C, in different types of targets. When people already use C to do job X, and see X could be done better by modifying the language a bit, they ask for compiler writers to add this option. And they do it instead of coming up with a new language.

Prerequisite for this is, C has to be "kinda almost good enough". The bar does not need to be very high, but it can't be total and utter crap, either.

Part of the popularity is of course non-technical, as always. Successful technologies typically combine "good enough" with right timing and other specifics, and then they gain the momentum needed.

And the extensions have helped keep that momentum going. And I love the anger it causes in C hateboys, because in their world view, having extensions is a sign of weakness and such lead to the demise of the language, but in actual reality opposite is true, and no one is interested in admitting a weakness if you still win.

[MK14]

That's exactly how I manage to to "solved" my problems.

20x the code size you would get with C89 and 20x slower (-O1 is the only one implemented at the moment).
As a benefit it simplifies both ICE-testing(1) and ICE-coverage.

That's fine, if that is what you want.  Potentially easier/faster debugging, and possibly significantly less development time, and (for some people) disliked debugging time.

But some languages, enforce such a scenario, all the time, to varying extents.  Which means, you can't easily produce a very fast/efficient version (although other(s) have pointed out, that some modern languages, attempt to offer BOTH advantages, simultaneously (i.e. fast/efficient AND safe), by smart language design), which might be desirable, come release/production day.

If safety and/or robustness/reliability and the highest quality levels, are needed or desired.  Such flag options (in C), or languages that do things like that by default or even always.  Will be desirable for some programmers, doing some kinds of work.

[Marco]

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.

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.

[Sherlock Holmes]

i dont get your analogy... what different vendor extensions? what different standards? and what are you suggesting as better alternative? i will looking forward to look up vendor extensions and different standards on the better language you are suggesting.

Arm C Language Extensions

Microsoft extensions to C

Nvidia C Language extensions

Microchip C Language extensions

Ahh, the old "what are you suggesting as better alternative" defense, how predictable.

you doing sort of informal fallacy on C. just because its so extensible by nature, which is imho is a big plus, so every vendors is doing extension to it in their own way, i also made my own extended library complete with bulletproof boundary check classes, so that made me the 15th standards which is bad? (but luckily i dont publish, its for my own). what do you expect? M$ style of driver certification where each vendor should comply to certain standards set by the committee? and possibly pay for the certification? M$ got heavy bashing for this, no? how could you satisfy all? are you going to make a language that only you you can extend it? good luck! python faced the same compatibility issue! on ever expanding library/extensions

Did you really write "its so extensible by nature"? I've really heard it all now. Like many things in computing different people often mean different things when they use certain words. Arguably assembler lets you "do anything you want" and assembler is "extensible by nature" too. Qualities that every language possesses are obviously not qualities one can use to compare those languages.

You already know some of the reasons I think C is a poor language, I've already described some of these to you in other threads.

It has no string or bit data types, it has a contrived clumsy way to let you declare bit fields, it doesn't let you access bits in bit fields using array subscript notation, it has no support for catching and handling divide by zero or null pointer references, it treats assignments as expressions, it restricts you to always base array elements starting at zero, it restricts you to map arrays in only on direction, it forces you to "forward declare" functions, it uses the term "static" to mean "private" but in other contexts it means something else.

It has the totally useless keyword "void" which litters the source code and header files (and that has contaminated many languages since including C++, Java, C#...), it has reserved words (as do all derivatives of C). It's one of the oldest and feeblest programming languages still in regular use, it's dated, stuck in the past, hampers productivity, confuses new users with silliness like ++I and J-- and so on.

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.

[MK14]

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.

[Sherlock Holmes]

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 to old and using outdated language specifications, to try out.

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

I do think the standards documents should be free, some of the stuff on the ANSI standards website could be given away, not making standards free hampers their spread I think.

[Mechatrommer]

It has no string or bit data types, it has a contrived clumsy way to let you declare bit fields, it doesn't let you access bits in bit fields using array subscript notation, it has no support for catching and handling divide by zero or null pointer references, it treats assignments as expressions, it restricts you to always base array elements starting at zero, it restricts you to map arrays in only on direction, it forces you to "forward declare" functions, it uses the term "static" to mean "private" but in other contexts it means something else.

It has the totally useless keyword "void" which litters the source code and header files (and that has contaminated many languages since including C++, Java, C#...), it has reserved words (as do all derivatives of C). It's one of the oldest and feeblest programming languages still in regular use, it's dated, stuck in the past, hampers productivity, confuses new users with silliness like ++I and J-- and so on.

man i think i'm pretty clear what you are after. i dont want to go further with this type of argument, you have every right to not be happy with it. will be looking forward to see your new invention.

[DiTBho]

The Ada-SPARK / ADA type languages

Direct experience: AdaMulti(GreenHills) + Trace/Nexus(Lauterbach).

[DiTBho]

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