any examples of OS not written in C/C++?

[tggzzz]

After this project, I'd like to play with a simple OS not written in C/C++.
I mean, I like to compile (modify?) some good piece of code, upload something on a board (68k? modern STM32?), and play with it.

Ada? Pascal? Modula2? Oberon? Assembly? All welcome

Other than assembly language, those are all isomorphic to C/C++, certainly the GNU version if not the standard (e.g. with nested functions possible). They differ only in surface syntax, the standard library, and things such as how visibility of names is controlled. Generate code is identical. The same goes for Lisp.

Really? You can get buffer overflow in Ada using the normal cliche programming style? Or access/mutate aCamel as if it was aHorse?

You don't get buffer overflows in properly-written C (or especially C++) code.

I wondered how long it would be until the There's No True Scotsman fallacy would rear its head!  https://en.m.wikipedia.org/wiki/No_true_Scotsman

That is an unfair statement.

Unlike C++, C has two different "modes": hosted environment and freestanding environment.  The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).

Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment.  It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.

Therefore, this is not a No True Scotsman argument, because it identifies the problematic but optional half of C.  I know this, because I myself am working on a "better" substitute (for my own needs and uses).

So you think it is an acceptable argument to exclude "half" of C uses and concentrate on the less inconvenient other half?

No, I think it is an error to consider hosted C environment the only valid C, and call relying on freestanding C 'excluding "half" of C', when the main problems are all in the hosted C environment only.

The above linked argument is not a case of No True Scotsman, exactly because of the dual nature of the C standard, and the problems being avoidable by using freestanding C.  It is a valid argument, because many C developers are not aware of the differences between the hosted environment and the freestanding environment, and conflate the two.

(Technically, one does not even need to write freestanding C, just avoid using most of the standard C library API; and use other APIs, like say Boehm GC for memory allocation, and mutable data buffers with explicit bounds instead of standard C strings, to basically completely avoid both buffer overruns and dynamic memory management problems.)

I fully agree that the C standard committee has dropped the ball over two decades ago, mainly due to increased vendor pressure and complete rejection of the POSIX standard, and instead veering into C++ and vendor-specific optional interfaces (like the so-called "safe I/O functions", which are nothing of the sort).

Put another way, buffer overruns and dynamic memory management issues are not an inherent part of C; only an inherent part of the library that forms the core of the hosted C environment: the standard C library.  It is quite possible, and indeed very feasible, to either replace, or just augment the standard C library with something completely different that 1) does not suffer from buffer overruns because array boundaries are part of the data structures used by the replacement library interfaces, and 2) has an efficient automatic garbage collection; and the code will still be C that a typical C developer will be able to read and maintain.  To develop such code, a typical C developer will have to learn those new interfaces, but that's it.

Having experimented and delved into this, it amazes me that no real work has been published on this front, because I'm basically drowning in possibilities and having to write a lot of test code just to see which options I prefer right now, for code running under the Linux kernel on typical ARM and Intel hardware.
To me, it feels like computer scientists are arguing amongst themselves how many sides should a polygonal wheel have, completely ignoring round, circular wheels... We really have not made much real progress in software engineering (and I'm suspecting in computer science too) in the last two or three decades.  Small optimizations only.
Things like the Arduino library (which replaces the standard C library for Arduino development; and although the code is compiled using a C++ compiler, it relies on the GNU C++ compiler providing a freestanding C++ environment based on the C freestanding environment) are honestly quite horrible, possibly even worse than the standard C library.  I shan't talk much about the various vendor-provided Hardware Abstraction Libraries, just that every single one I've seen has been a disappointment (in the software engineering sense – compare to a contractor seeing a house built with timber but using twine instead of nails or screws (or even pegs) to hold things together).

The dual nature is important to realize, because the non-library part of C is so simple yet powerful.  It could be much better (code-level concurrency, barriers, memory semantics/coherency etc.), but that sort of stuff is better explored with other languages.  However, the C library part, which is not a compulsory/required part of C, only an optional part, is the biggest problem with C, and is easily replaced with something else. (That is, all C compilers I have used, provide compile time flags and options that allow trivially replacing/omitting the standard C library with something else.)

Thanks for a thoughtful and nuanced post. I stand by my original points.

I thank you for providing even more points indicating why C/C++ has become part of the problem rather than a solution.

I'll highlight and comment on a few of your points below...

many C developers are not aware of the differences between the hosted environment and the freestanding environment, and conflate the two.

Which is unsurprising, since the committee and language conflate the two - to the detriment of both.

I fully agree that the C standard committee has dropped the ball over two decades ago, mainly due to increased vendor pressure

I'm unconvinced vendor pressure was the main reason for problems. As one example, the "cast away constness" dilemma is a fundamental consequence of the application domains and fundamental properties of the language.

Put another way, buffer overruns and dynamic memory management issues are not an inherent part of C;

Not true, since pointers can point to anything including memory outside buffers - and neither the language nor runtime can detect it. There are common workarounds/clichés, but they rely on programmers religiously understanding and following the workarounds/clichés - and in many environments there are incentives working against that. In an ideal world that wouldn't be the case, but here on planet earth...

To me, it feels like computer scientists are arguing amongst themselves how many sides should a polygonal wheel have, completely ignoring round, circular wheels... We really have not made much real progress in software engineering (and I'm suspecting in computer science too) in the last two or three decades.  Small optimizations only.

I tend to agree, unfortunately. When returning to embedded programming recently, I was horrified at how little had changed since the early 80s.

However, there have been some advances since then, notably decent OOP, and the recognition that single-threaded code is no longer a good starting point and must be a designed pre-requisite in the future. The latter is currently far from perfect, and I hope more advances will be made - but there are promising signs.

Things like the Arduino library ... are honestly quite horrible, possibly even worse than the standard C library.  I shan't talk much about the various vendor-provided Hardware Abstraction Libraries

Agreed, but I don't think the language can be blamed for those! It is, however, a shame that it didn't encourage better.

McCormicks well known Ada vs C model railroad experiments threw up some surprising insights http://archive.adaic.com/projects/atwork/trains.html

The dual nature is important to realize, because the non-library part of C is so simple yet powerful. 

Powerful, but not simple. And the dual nature means it is an unsatisfactory fudge for both.

It could be much better (code-level concurrency, barriers, memory semantics/coherency etc.), but that sort of stuff is better explored with other languages. 

Those are fundamental and it is finally being recognised that they are critical in multiprocessor systems. And even cheap embedded systems are multicore nowadays.

However, the C library part, which is not a compulsory/required part of C, only an optional part, is the biggest problem with C, and is easily replaced with something else.

Technically perhaps, but practically and commercially not!

[thinkfat]

Using C without the standard library doesn't make it any safer or more secure as a language. Proof of which is the long history of Linux kernel level exploits. Or exploits in no-OS network appliances. The MITRE database is a good place to look for examples.

To think that "libraries" are somehow a problem and not using them will improve the situation is odd. It is simply difficult to write secure code in C. It requires a certain mindset and a lot of experience. Rare traits in the industry.

[coppice]

Using C without the standard library doesn't make it any safer or more secure as a language. Proof of which is the long history of Linux kernel level exploits. Or exploits in no-OS network appliances. The MITRE database is a good place to look for examples.

To think that "libraries" are somehow a problem and not using them will improve the situation is odd. It is simply difficult to write secure code in C. It requires a certain mindset and a lot of experience. Rare traits in the industry.

The original standard C library is certainly a problem. Its full of functions with no internal size checks. A good library isn't a magic cure for problems, but the original standard C library is like a banana skin.

[tggzzz]

Unlike C++, C has two different "modes": hosted environment and freestanding environment.  The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).

Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment.  It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.

If you believe that, how do you explain the regular exploits like:
   100 Million More IoT Devices Are Exposed and They Won't Be the Last (WiReD)
   Gabe Goldberg <gabe@gabegold.com>
   Wed, 14 Apr 2021 19:41:06 -0400
   The Name:Wreck flaws in TCP/IP are the latest in a series of vulnerabilities with global implications.
   https://www.wired.com/story/namewreck-iot-vulnerabilities-tcpip-millions-devices/
or
   A Casino Gets Hacked Through a Fish-Tank Thermometer (Entrepeneur)
   Amos Shapir <amos083@gmail.com>
   Fri, 16 Apr 2021 17:49:35 +0300
   Hackers gain entry to a casino's internal net via a fish tank, and steal list of customers:
   https://www.entrepreneur.com/article/368943

Both of those are from the yesterday's comp.risks (Volume 32 Issue 60 Saturday, 17th April 2021), which everybody should be reading.
See https://catless.ncl.ac.uk/Risks/

[bd139]

Can't believe I missed this thread. Right up my street.

100% agree with you. There is no way to make C and/or C++ a "safe" environment to write software in. It is absolutely 100% impossible. The problem is the compiler's fundamental model is memory regardless of what suit you dress your code in, whichever macros or libraries you use, whether or not Coverity have buggered you for cash or not and whether or not you have used clever compiler features to trip up people attacking your code.

99% of programs written though, why the hell would you give the average "engineer" (in quotes intentionally) two loaded shot guns, a backpack full of knives. All they're going to do is spread their own form of electric ebola...

These days if we need suitable guard rails, we look towards fully managed runtimes (think Java, .Net, Python) and better abstracted memory-safe languages (Go) even at system level. That covers that crapfest nicely, leaving the entire class of application domain bugs open instead which is more than enough of a problem on its own without having to worry about driving up the pavement into a lamp post.

I don't really give a fuck about the OS quite frankly though. The key thing is it's as small as possible and lets me run my programs without getting in the way of them. Amazon will rent you a nice mainframe that hides that from you.

Edit: I didn't even mention rust. Discounted due to certain people marketing it as Jesus' sandals. Been around long enough to know what's going to stick and what isn't.

[tggzzz]

Can't believe I missed this thread. Right up my street.

100% agree with you. There is no way to make C and/or C++ a "safe" environment to write software in. It is absolutely 100% impossible. The problem is the compiler's fundamental model is memory regardless of what suit you dress your code in, whichever macros or libraries you use, whether or not Coverity have buggered you for cash or not and whether or not you have used clever compiler features to trip up people attacking your code.

Precisely.C/C++ memory is untyped, even if the variables are strongly typed. Fashionable modern languages tend to have strongly typed memory and untyped variables.  Personally I like strongly typed memory and typed variables.

[thinkfat]

Using C without the standard library doesn't make it any safer or more secure as a language. Proof of which is the long history of Linux kernel level exploits. Or exploits in no-OS network appliances. The MITRE database is a good place to look for examples.

To think that "libraries" are somehow a problem and not using them will improve the situation is odd. It is simply difficult to write secure code in C. It requires a certain mindset and a lot of experience. Rare traits in the industry.

The original standard C library is certainly a problem. Its full of functions with no internal size checks. A good library isn't a magic cure for problems, but the original standard C library is like a banana skin.

Yes, of course strcpy() and the like are obviously problematic, but there are countless patterns of unsecure code aside from that. The concept of pointer arithmetics or integer indices to access arbitrary memory locations, while mightily convenient for low-level hardware hacking, is inherently unsafe. Not to mention the plethora of cases where behavior is simply "undefined" in C.

[bd139]

Yep. There's even a competition to see what you can get away with 

http://www.underhanded-c.org/

This is a fun one from it:

Code: [Select]

typedef double float_t;


[Nominal Animal]

I stand by my original points.

I really only object to the No True Scotsman fallacy claim.

I'll highlight and comment on a few of your points below...

I understand your points, and fully acknowledge their basis in facts; I only disagree on some of your conclusions.

As an example, consider PHP, a widely used but usually pretty horrible code.  Especially its earlier versions were basically a security hole waiting to happen (magic quotes stuff in particular).  Yet, one could write quite secure web service code with it, if one paid sufficient attention, and avoided using the features that usually lead to security problems.  I know, because I have.

However, many of those security holes have been plugged (like magic quotes no longer supported, database interfaces switching from building query strings to using variable references so quoting is not even an issue, and so on).  The most problematic design principle currently is that most PHP services are designed to be able to upgrade themselves, which necessarily means the installation is vulnerable to script drops/bombs et cetera.  We could avoid that, and even things like password leaks, if we leveraged the POSIX/Unix user and group hierarchies, with server interpreters refusing to execute code owned by the user that can upload content to the server; and login/logout/account management facilities restricted to a few specific pages with all others not even having access to the sensitive fields of the user database...

We could do better with Python, but unfortunately Python insists on its "own" WSGI interfaces (as opposed to say FastCGI).  (In particular, a page engine can be written as a FastCGI script, with each request (connection) served by a forked child.  The engine can preload each instance by the main data structures, like navigation and file types supported, deduplicating most of the work done by most page loads.)  As a result, typical widely used Python-based web services are vulnerable to similar bugs as PHP ones, on top of its own WSGI ones!  No true forward development, just.. steps in odd directions, in my opinion.

This "proves" to me that the current software bugs and insecurity is really not a feature of the respective programming languages, but a consequence of us human developers accepting a software "engineering" culture that has discarded almost all good engineering principles, and is just sticking stuff together with spit and bubblegum, banking on the product working just long enough that they won't be held responsible for the crappiness.  And that we should not blame the languages for not trying to stop the developers for implementing idiotic designs.

(I am not sure whether I can even honestly call *current* PHP versions an insecure programming language, anymore.  I have in the past, especially due to features like magic quotes that attempts to hand-hold bad developers; but the removal of such has removed my reasons.  Granted, I haven't written security-sensitive PHP in almost a decade now, so I am out of touch.)

There is no way to make C and/or C++ a "safe" environment to write software in. It is absolutely 100% impossible.

I agree; but I also think it is not necessary for a systems programming language to be "safe".

That is, one of the reasons I think C is powerful, is exactly because it does not try to stop developers from shooting themselves in the face with pointers et cetera.

Anyway, it is technically possible to write secure, robust C code.  It is just much easier to write horribly buggy and insecure C code.  At the core is (at least my observation that) making the language "safe" seems to also make it less powerful, harder to interface to, and/or slower: not exactly acceptable tradeoffs for the kind of situations C is used for.

Can we do better?  Absolutely we can!  But personally, I'm checking out the cost/benefit ratio of reaching for the low-hanging fruit first, by replacing the standard C library with something better suited for systems programming, to see how much better it would be.  Perfect is the enemy of good.

[SiliconWizard]

Can low level programming be made totally "safe" just from features of the language itself?

Rust if often considered for replacing C in that area lately. But I've also read a couple papers that tend to show any serious low-level programming in Rust would require the use of "unsafe" sections of code, and that "unsafe" Rust is NOT provably any better than C. Of course you can restrict the use of unsafe sections to the strict minimum needed, whereas in C, any portion of code could be seen as unsafe - as per the Rust definition. So while it is natural to assume that it would drastically lower the probability of bugs and exploits, it remains to be proven in practice, at the level of a full OS for instance.

I agree with Nominal Animal about good engineering practice being largely replaced with silver bullets and tools.

Now C (and C++) certainly allows developers to do particularly nasty things with memory. Yes it's spectacularly easy to do so.

Various security reports I have read don't show C as the language with the most security exploits though in practice. I would have to dig a little now to provide links, but AFAIR, PHP, Javascript and even Java came largely sad winners here. It doesn't necessarily show anything related to the languages themselves though, but rather *how* (and probably by whom) they are typically used.

[Nominal Animal]

Unlike C++, C has two different "modes": hosted environment and freestanding environment.  The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).

Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment.  It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.

If you believe that, how do you explain the regular exploits like:
   100 Million More IoT Devices Are Exposed and They Won't Be the Last (WiReD)
   Gabe Goldberg <gabe@gabegold.com>
   Wed, 14 Apr 2021 19:41:06 -0400
   The Name:Wreck flaws in TCP/IP are the latest in a series of vulnerabilities with global implications.
   https://www.wired.com/story/namewreck-iot-vulnerabilities-tcpip-millions-devices/
or
   A Casino Gets Hacked Through a Fish-Tank Thermometer (Entrepeneur)
   Amos Shapir <amos083@gmail.com>
   Fri, 16 Apr 2021 17:49:35 +0300
   Hackers gain entry to a casino's internal net via a fish tank, and steal list of customers:
   https://www.entrepreneur.com/article/368943

Both of those are from the yesterday's comp.risks (Volume 32 Issue 60 Saturday, 17th April 2021), which everybody should be reading.
See https://catless.ncl.ac.uk/Risks/

I explain those by pointing out that possible ≠ easy.

It is much, much easier to write buggy C than it is to write robust, secure C code.  C is a dangerous tool, but so powerful and useful that many choose to use it nevertheless.

Nothing is perfect, so where do you draw the line for "safe"?  Even if the code is guaranteed to work perfectly for all possible inputs on standard hardware, there are glitches.  Most current AMD64 architecture laptop and desktop machines do not support ECC memory, so single-bit errors can occur because of an odd cosmic ray, or for a number of other reasons.

I don't think it is a No True Scotsman argument to say something like "a properly trained person will never point a firearm at anything or anyone, even when the safety is on, unless they are ready to kill them".  This is a simple rule known for as long as firearms have existed; but the firearm itself does not enforce the rule.  A lot of people (including soldiers) do not know or neglect to follow that rule, so accidents happen, and people get killed.  With C, bugs and security failures occur often because the developers do not care (about making the code secure against unexpected inputs); I've heard countless times that "we don't have the time for that right now; we'll add those in later".

[tggzzz]

I stand by my original points.

I really only object to the No True Scotsman fallacy claim.

I'll highlight and comment on a few of your points below...

I understand your points, and fully acknowledge their basis in facts; I only disagree on some of your conclusions.

As an example, consider PHP, a widely used but usually pretty horrible code.  Especially its earlier versions were basically a security hole waiting to happen (magic quotes stuff in particular).  Yet, one could write quite secure web service code with it, if one paid sufficient attention, and avoided using the features that usually lead to security problems.  I know, because I have.

However, many of those security holes have been plugged (like magic quotes no longer supported, database interfaces switching from building query strings to using variable references so quoting is not even an issue, and so on).  The most problematic design principle currently is that most PHP services are designed to be able to upgrade themselves, which necessarily means the installation is vulnerable to script drops/bombs et cetera.  We could avoid that, and even things like password leaks, if we leveraged the POSIX/Unix user and group hierarchies, with server interpreters refusing to execute code owned by the user that can upload content to the server; and login/logout/account management facilities restricted to a few specific pages with all others not even having access to the sensitive fields of the user database...

We could do better with Python, but unfortunately Python insists on its "own" WSGI interfaces (as opposed to say FastCGI).  (In particular, a page engine can be written as a FastCGI script, with each request (connection) served by a forked child.  The engine can preload each instance by the main data structures, like navigation and file types supported, deduplicating most of the work done by most page loads.)  As a result, typical widely used Python-based web services are vulnerable to similar bugs as PHP ones, on top of its own WSGI ones!  No true forward development, just.. steps in odd directions, in my opinion.

Not knowing PHP (because web servers bore me almost as much as databases), I presume your comments are correct. However PHP's awfulness doesn't make C any better.

As for Python, it seems reasonable enough except for

• repeating (in spades!)the makefile mistake where whitespace is semantically important
• the global interpreter lock, which avoid all sorts of problems at the expense of removing many interesting and useful performance properties

This "proves" to me that the current software bugs and insecurity is really not a feature of the respective programming languages, but a consequence of us human developers accepting a software "engineering" culture that has discarded almost all good engineering principles, and is just sticking stuff together with spit and bubblegum, banking on the product working just long enough that they won't be held responsible for the crappiness. 

I completely agree, unfortunately.

And that we should not blame the languages for not trying to stop the developers for implementing idiotic designs.

Again, agreed.

But when the fundamental properties of a language mean that large applications are "castles built on sand", we shouldn't shy away from recognising that choosing a different language ought to mean the "castle is built on rock". It is, of course, possible to choose a different language so that the "castle is built on a swamp".

We should distinguish swamps and sand from rock, and choose rock whereever possible.

[tggzzz]

Can low level programming be made totally "safe" just from features of the language itself?

I doubt it. Halting problem and all that.

But that isn't a reason for choosing a language that avoids common problems.

I agree with Nominal Animal about good engineering practice being largely replaced with silver bullets and tools.

Good engineering practice requires avoiding use of inappropriate tools. There are no silver bullets, but some tools will allow a bigger job to be finished faster and better - by letting you concentrate on the application's problem rather than the tools' problems.

Various security reports I have read don't show C as the language with the most security exploits though in practice. I would have to dig a little now to provide links, but AFAIR, PHP, Javascript and even Java came largely sad winners here. It doesn't necessarily show anything related to the languages themselves though, but rather *how* (and probably by whom) they are typically used.

Naively counting such things rarely leads to enlightenment!

[tggzzz]

Unlike C++, C has two different "modes": hosted environment and freestanding environment.  The former includes the standard C library – including functions like fgets(), strcpy(), and so on –; whereas the latter is used when programming kernels and microcontrollers, often with a replacement set of functions (see Linux kernel C functions, or the Arduino environment, for examples).

Buffer overflows are intrinsic part of the C standard library, but not the C freestanding environment.  It is quite possible to replace the standard C library with a completely different API, including arrays with explicit bounds and garbage collection, but keep the C compiler and syntax.

If you believe that, how do you explain the regular exploits like:
   100 Million More IoT Devices Are Exposed and They Won't Be the Last (WiReD)
   Gabe Goldberg <gabe@gabegold.com>
   Wed, 14 Apr 2021 19:41:06 -0400
   The Name:Wreck flaws in TCP/IP are the latest in a series of vulnerabilities with global implications.
   https://www.wired.com/story/namewreck-iot-vulnerabilities-tcpip-millions-devices/
or
   A Casino Gets Hacked Through a Fish-Tank Thermometer (Entrepeneur)
   Amos Shapir <amos083@gmail.com>
   Fri, 16 Apr 2021 17:49:35 +0300
   Hackers gain entry to a casino's internal net via a fish tank, and steal list of customers:
   https://www.entrepreneur.com/article/368943

Both of those are from the yesterday's comp.risks (Volume 32 Issue 60 Saturday, 17th April 2021), which everybody should be reading.
See https://catless.ncl.ac.uk/Risks/

I explain those by pointing out that possible ≠ easy.

It is much, much easier to write buggy C than it is to write robust, secure C code.  C is a dangerous tool, but so powerful and useful that many choose to use it nevertheless.

And so the obvious conclusions are that in most cases C isn't the most appropriate tool, and that we should continue to search for better replacements.

Nothing is perfect, so where do you draw the line for "safe"?  Even if the code is guaranteed to work perfectly for all possible inputs on standard hardware, there are glitches.  Most current AMD64 architecture laptop and desktop machines do not support ECC memory, so single-bit errors can occur because of an odd cosmic ray, or for a number of other reasons.

From yesterday's comp.risks, again
   Cosmic rays causing 30,000 network malfunctions in Japan each year (The Japan Times)
   Dave Farber <farber@keio.jp>
   Mon, 5 Apr 2021 12:30:51 +0900
   https://www.japantimes.co.jp/news/2021/04/04/business/tech/ntt-cosmic-rays/
   https://cdn-japantimes.com/wp-content/uploads/2021/04/np_file_79612.jpeg
   The Japan Times, 4 Apr 2021 (Bloomberg)
   Nippon Telegraph and Telephone Corp. has found that cosmic rays are causing an estimated 30,000 to 40,000 temporary malfunctions in domestic network communication devices in Japan every year.
   ...
   https://catless.ncl.ac.uk/Risks/32/60#subj3

However telecom systems are designed and implemented with the presumption that errors will occur and bits of the network will disappear without warning.

I don't think it is a No True Scotsman argument to say something like "a properly trained person will never point a firearm at anything or anyone, even when the safety is on, unless they are ready to kill them".  This is a simple rule known for as long as firearms have existed; but the firearm itself does not enforce the rule.  A lot of people (including soldiers) do not know or neglect to follow that rule, so accidents happen, and people get killed.  With C, bugs and security failures occur often because the developers do not care (about making the code secure against unexpected inputs); I've heard countless times that "we don't have the time for that right now; we'll add those in later".

Defects in a "castle built on sand" do not excuse building on sand rather than on rock.

[Ed.Kloonk]

I'm not sold on the C/C++ is evil because of the dreaded buffer overrun. Some asshat can make some sloppy C code and chances are good it will only crash at best. But an interpreter, ironically written in C, could have a bug which could expose 100s of thousands of users to an exploit.

[bd139]

I'm not sold on the C/C++ is evil because of the dreaded buffer overrun. Some asshat can make some sloppy C code and chances are good it will only crash at best. But an interpreter, ironically written in C, could have a bug which could expose 100s of thousands of users to an exploit.

Better that exploit gets fixed in one patch than 100,000 independent programs in C that don’t.

[tggzzz]

I'm not sold on the C/C++ is evil because of the dreaded buffer overrun. Some asshat can make some sloppy C code and chances are good it will only crash at best. But an interpreter, ironically written in C, could have a bug which could expose 100s of thousands of users to an exploit.

Better that exploit gets fixed in one patch than 100,000 independent programs in C that don’t.

Which is also a classic argument in favour of languages that support garbage collectors

Doubly so for languages where every developer creates their own reference counting garbage collector.

[bd139]

It’s even lower level than that. Solve a problem once, properly. Not a million times, badly.

Applying that to C is fairly easy.

[tggzzz]

It’s even lower level than that. Solve a problem once, properly. Not a million times, badly.

NIH is endemic in the C++ community, from acadaemia to grunts in the trenches.

Too many of the academic papers on C++ reference only other C++ papers. To give a contrary example, Gosling's Java whitepaper was notable for nicking concepts from many other languages, where each concept had been proven in practice and all concepts played nicely with each other.

[bd139]

It’s even lower level than that. Solve a problem once, properly. Not a million times, badly.

NIH is endemic in the C++ community, from acadaemia to grunts in the trenches.

Too many of the academic papers on C++ reference only other C++ papers. To give a contrary example, Gosling's Java whitepaper was notable for nicking concepts from many other languages, where each concept had been proven in practice and all concepts played nicely with each other.

I think that’s out of necessity. Someone has to write their own “framework” at every C++ house I’ve seen and work to some poorly defined subset of the language which doesn’t have so many foot guns.

Rust is the same. But the academic papers are blog posts and brigading on tech news aggregators.

Similar with Go. It’s that fuzzy joy that Java was (if you avoided J2EE 1.x )

[tggzzz]

It’s even lower level than that. Solve a problem once, properly. Not a million times, badly.

NIH is endemic in the C++ community, from acadaemia to grunts in the trenches.

Too many of the academic papers on C++ reference only other C++ papers. To give a contrary example, Gosling's Java whitepaper was notable for nicking concepts from many other languages, where each concept had been proven in practice and all concepts played nicely with each other.

I think that’s out of necessity. Someone has to write their own “framework” at every C++ house I’ve seen and work to some poorly defined subset of the language which doesn’t have so many foot guns.

One of the notable points about Java was the speed with which a wide range of high quality libraries became available, and which played nicely with each other. C++ had failed to do that in a decade, and is still playing catch up.

Rust is the same. But the academic papers are blog posts and brigading on tech news aggregators.

Similar with Go. It’s that fuzzy joy that Java was (if you avoided J2EE 1.x )

I'm ambivalent about Go and Rust, but they have a good starting point in that they've nicked concepts from CSP

I kicked the tyres of J2EE (but not the development environments for it!), looked at Spring, and evaluated a JAIN implementation. For real work in a telecoms server,  I/we created a small library that very favourably surprised other engineers and companies.

[Ed.Kloonk]

I'm not sold on the C/C++ is evil because of the dreaded buffer overrun. Some asshat can make some sloppy C code and chances are good it will only crash at best. But an interpreter, ironically written in C, could have a bug which could expose 100s of thousands of users to an exploit.

Better that exploit gets fixed in one patch than 100,000 independent programs in C that don’t.

Only after the impact of a high-yield exploit which had been refined to maximize the damage verses random programs with bad code that hackers can't be bothered attacking.

[tggzzz]

I'm not sold on the C/C++ is evil because of the dreaded buffer overrun. Some asshat can make some sloppy C code and chances are good it will only crash at best. But an interpreter, ironically written in C, could have a bug which could expose 100s of thousands of users to an exploit.

Better that exploit gets fixed in one patch than 100,000 independent programs in C that don’t.

Only after the impact of a high-yield exploit which had been refined to maximize the damage verses random programs with bad code that hackers can't be bothered attacking.

As usual it is a case of choosing your poision.

However, given state sponsored and criminal gang sponsored efforts, I'm not sure that it is possible to claim "hackers can't be bothered attacking". The "hack a fishtank thermometer" I mentioned is a good counter example.

[bd139]

I'm not sold on the C/C++ is evil because of the dreaded buffer overrun. Some asshat can make some sloppy C code and chances are good it will only crash at best. But an interpreter, ironically written in C, could have a bug which could expose 100s of thousands of users to an exploit.

Better that exploit gets fixed in one patch than 100,000 independent programs in C that don’t.

Only after the impact of a high-yield exploit which had been refined to maximize the damage verses random programs with bad code that hackers can't be bothered attacking.

Nope.

This is one of about 100 different concerns when it comes to information security. The holistic picture is more important than a specific vulnerability. You have to layer your defences because they are not perfect or reliable independently.

Better to have multiple layer mitigation. But keeping that surface area small is vastly important.

In our case there’s a respectable WAF between public and ingress. And no ingress services are written in C.

[Nominal Animal]

And that we should not blame the languages for not trying to stop the developers for implementing idiotic designs.

Again, agreed.

But when the fundamental properties of a language mean that large applications are "castles built on sand", we shouldn't shy away from recognising that choosing a different language ought to mean the "castle is built on rock". It is, of course, possible to choose a different language so that the "castle is built on a swamp".

Fully agreed.

Problem is, every programming language we currently have, have their drawbacks.  I "solve" this by using multiple programming languages; for example, Python for UI, C for heavy computation (in a library form).  I automate tasks using Bash or POSIX shell scripts, Makefiles, and Awk; the latter is especially useful for certain line/record based format data processing.  I try to pick each tool, each programming language, that seems the most appropriate for each task at hand, while being careful to not let my personal preferences skew the choice too much.

Now that Rust has its own foundation, I'm hoping it will become a reasonable alternative to systems level programming.  I dislike Go for the same reasons I dislike .Net: being single vendor controlled projects, their future is uncertain; and I've been bitten by single vendor products often enough to be wary of subjecting myself to those if reasonable alternatives exist.

We should distinguish swamps and sand from rock, and choose rock whereever possible.

Absolutely!  But, what would be the rock-analog to replace the swamp and sand that is C, in systems programming?  (Specifically, efficient low level libraries and services interfaced to from higher level languages, for my own use cases?)  I personally do not know of one.

So, I personally am trying to use piling (driving heavy stilts or posts into the swamp and sand to create a stable enough base to build on; an analog for replacing just the standard C library with something better, more suited to the task), until those better than I in computer science can develop a language that can achieve the same or better end results.

(For example, having carefully considered and tested various cases, I've changed my mind regarding garbage collection.  I do "like" pool based allocation more, but in objective terms, good garbage collection schemes simply have fewer drawbacks.)