[soraminazuki]

> persistent but bad practices in the open source community (e.g., a stubborn refusal to stop using C-like memory management semantics and primitives when dealing with untrusted inputs)

This applies to the entire industry. It's not something specific to the open source community. It's also extreme to call the use of C as "bad practice," as any language has its own strengths and weaknesses.

[pjmlp]

Not the entire industry, as many companies have thankfully moved on from plain old C, or at very least reduced its use quite considerably.

BSD/Linux derived FOSS is still the C stronghold.

The Morris worm was in 1988, since then C has collected enough CVEs due to memory corruption issues to consider its use bad practice.

Something that even Apple, Google and Microsoft security reports now advise against, and with Google actively engaging into taming C's usage in Linux kernel.

[Nursie]

> BSD/Linux derived FOSS is still the C stronghold.

Oh that's ok then, it's not like that accounts for most of the world's server and embedded infrastructure, open or otherwise...

[orbifold]

The operating system is only a tiny fraction of commercial code out there most of which is either written in (more) memory safe languages like Java, C# or C++. SAPs code base alone is 1 billion lines of mostly C++ and their own proprietary scripting language.

[Nursie]

Wait, is C++ memory safe?

I know they've introduced a lot of ways that memory management becomes easier or automatic, but I'm not sure you can call it "memory safe" can you?

[pjmlp]

Not to the extent that it is tainted by C's copy-paste compatibility.

Still it does provide a stronger type system, proper string, vectors, reference paramenters and strong type enumerations, to prevent a large amount of C security exploits.

C++ teams that care about security do use such features and respective static analysers on their CI/CD to enforce them.

While it doesn't cover everything, it is much safer than plain C.

Ideally, we will reach a state where both C and C++ get nuked, or ISO C++ just drops its C copy-paste compatibility, which in the end means it is anyway easier to switch to something else.

However that process will take decades, and is hampered by relying on POSIX based systems.

[pjmlp]

How are they doing in the desktop and mobile OS worlds?

And regarding embedded space, AUTOSAR now requires C++14.

I think there are enough computers with wheels to deem it relevant.

[Nursie]

Desktops are dwarfed by mobiles devices. AFAICT a linux kernel variant is present on most of the world's smartphones (with most of the rest being iOS devices, which I know little about), though you've addressed that by saying Google are pushing to reduce the impact of C underlying their system.

I don't want to make a song and dance about C being awesome or anything - we've certainly got massive issues with allowing that extreme amount of flexibility without ensuring that the developer really, really means what they've just told the machine to do - but it's hardly a small enclave that's holding out, it's still huge.

And there are still companies developing in it. I've seen a sort-of-microservices-in-C-implemented-as-a-sort-of-supersized-cgi-bin approach relatively recently.

And yes it was an abomination!

[pjmlp]

So you want to talk about mobiles?

Windows Phone, JavaScript, .NET (VB and C#) and C++.

iOS, JavaScript, Objective-C, C++ and Swift, C only due to BSD stuff.

Android, Java, Kotlin, JavaScript, C++, C only due to Linux kernel. Its sucessor. Project Treble drivers use Java and C++. Fuchsia is written in a mixture of Rust, Dart, and C++.

ChromeOS, JavaScript, C++, Rust, C only due to Linux kernel

[Nursie]

> Windows Phone, JavaScript, .NET (VB and C#) and C++.

An irrelevance given their complete lack of market presence.

The rest all have significant underlying C components you've identified. All I'm saying is that's a hardly a 'niche holdout' when it appears to be at the heart of the vast majority of shipping devices.