Hacker News Reader

> C does work pretty well

Consider C's Biggest Mistake:

https://www.digitalmars.com/articles/b44.html

You can use D in -betterC mode, write code pretty much just like you would in C, and not have that problem.

> Consider C's Biggest Mistake

I do not think it is a significant problem in C. It might be more of a problem in C++.

> You can use D in -betterC mode, write code pretty much just like you would in C, and not have that problem.

D is an improved, more polished version of _C++_, not C; "-betterC" mode is misleading, it is more of a "betterC++" mode (features: classes, exceptions, RAII, templates).

"The simplicity of C is more useful than the additional features of C++." -- (Sam Watkins) s/C++/D/g

Don't get me wrong: D would be a great replacement for _C++_, but not C. For a better C I would look at a subset of Go (GC would have to go away).

D in "betterC" mode does not have GC, classes, exceptions, or RTTI. Nor does it need the D (or C) runtime library.

(It does have RAII without using exceptions.)

Thank you for clarification. I was looking at https://www.digitalmars.com/articles/betterC.html, https://dlang.org/spec/betterc.html is a better description.

>most of these other languages are ALSO open to the same security issues

How often do programs in non-C/C++ languages get remote code execution vulnerabilities? I'm sure the CVE numbers will overwhelmingly show that most RCE-capable vulnerabilities are in C/C++.

Sure, it occasionally happens in other languages, but practically only when someone does something like misuse one of a specific set of APIs that allow code loading. In C/C++, any code that slightly fucks up writing to an array or passes a pointer to previously-freed memory around can cause a RCE vulnerability that lets an attacker literally run code on your system and take it over. Inspecting a C/C++ codebase made by a junior person for vulnerabilities is a total nightmare. Inspecting a codebase in any other language for RCE vulnerabilities generally means you grep for a couple APIs and look at how they get used.

I don't believe that, you mention this because you put 100% trust on the runtime. When I see syntax like: var array=something[4...$] I don't see security there, all I see is someone pushing the problem further under the carpet, into the runtime.

So Sure, RIGHT NOW the runtime might be safe from scrutiny, but is it because its SAFE or just not as such a high profile, just yet?

On the other hand I DO agree that 'junior' programming will always be a problem, regardless of the matter, and pretty much, regardless of the language.

The difference is that if the bug is in the runtime you have to fix one place and everyone downstream gets that. If you solve one such bug in curl, you solved it just in curl.

EDIT: I thought about it a bit more and realized it cuts both ways. If you have an RCE in a standard library a lot of programs get an RCE for free while it's not patched. So yeah, a bit of a mixed bag.

There's also the difference that, in a GC'd language, you don't have both the language authors and the language users both competing to put these kinds of bugs in their software. :)

True, but when you want to interface between code written in two different GC'd languages then you can get similar problems if you're not careful. As the number and use of these various next generation languages proliferates, I suspect we might start to see more of that kind of thing appearing over time.

I posted a bit more beside this comment, but I think the difference isn't so much updates or code review but rather the design intention of the language. A language like Java or Python or Rust is designed for every operation to produce some defined behavior, and you can't generally trigger RCE unless you call some function like `unsafePerilousDangerZone(heinousRawPtr)`. Those design defaults bubbles up through libraries written in those languages, so that when you use other people's code and make a mistake, the result is either a crash or an unfortunate-but-at-least-well-defined logic bug. The opposite is true in C and C++, and that bubbles up through the libraries in those languages too.

[[Off-Topic - Sorry!]]

Hi Klez, I determined this to be the only way to get in touch regarding a previous discussion we had on Blendle [0] as I can no longer reply on that thread.

This was back in 2017 so they may have fixed their issues.

Alexander Klöpping <alexander.klopping@blendle.com> emailed me, I'll grant it was a generic welcome email, asking for feedback. I took the opportunity to email back informing him of the problems with using my email address [1]. I don't recall the problem now, but it seems they accepted my email address but then later rejected it during the sign-up process (as I clearly received an email correctly...).

I no longer have their response, but from memory, it was a different customer service person, and they rejected the idea that they had any problem AND/OR explicitly said they weren't going to make any changes. Oh, and they sent that response to the email that I explicitly said wouldn't work (it automatically gets sent to the trash to be deleted which is also why I don't have it any more).

Their rejection of fixing their service is what made me decide to put Blendle in the trash category.

[0]: https://news.ycombinator.com/item?id=20138213

[1]: My email, sent from X+Y@gmail.com

Dear Alexander Klöpping,

When I first heard about Blendle I was excited at the concept of being able to read high-quality journalism from multiple different sources through one - ad-free - platform and one reasonably-priced payment system, and so I signed up for the beta. I successfully started the process of joining Blendle by unlocking and selecting some preferences. However, I have been unable to proceed past entering my email address, X+Y@gmail.com. I should make it clear that the email address X@gmail.com cannot be used.

Could you please assist me and help me get started with Blendle?

Best,

[redacted]

Hey, thanks for replying to that question :) I guess I should give some way to contact me in my profile for cases like this.

> When I see syntax like: var array=something[4...$] I don't see security there, all I see is someone pushing the problem further under the carpet, into the runtime.

The runtime (whichever one that is) is safe because its behavior is defined by design for all inputs. Yes there could be a bug, but the design is that all inputs should be defined, and doing something for any given input isn't rocket science. Out of bounds array indexes either panic/throw or return empty lists. That can lead to crashes and logic errors, sure, or maybe DOS attacks, but it cannot lead to undefined behavior or remote code execution. That's a world of difference.

C and C++ by design expose heaps of undefined behavior to the caller. The tools for detecting UB are imperfect and don't work if the relevant inputs never show up in test cases. Even when veteran C coders develop the techniques and habits that let them write correct C, mistakes tend to show up at the integration points between libraries written by different people with different techniques and habits (https://youtu.be/HgtRAbE1nBM?t=2344).

That's kinda like claiming "a single implementation that everyone uses is no more secure/stable than a million independent implementations", which is fairly ridiculous. It's not (just) "pushing the problem further under the carpet", it's centralizing risk and attention and fixes, which does work out quite well in practice.

>all I see is someone pushing the problem further under the carpet, into the runtime.

How often are there bugs in language runtimes that cause vulnerabilities in programs that are exploitable by users putting in different data into an otherwise secure program? (I'm not talking about the case where the runtime has a sandbox that breaks when the user loads bad code into it; this is a use-case C/C++ don't even try to address so that would be comparing different things. I'm talking about cases where someone is running a program that communicates over the network and the program's own code is written correctly, but a problem in the runtime makes it so the program is vulnerable to remote code execution.) The main example I can think of like that was Shellshock, which was horrible, but I would never have held up Bash as an example of a safe language. Bash has always been on my short list next to C and C++ of languages to avoid because of how easy and common it is to make mistakes that are practically unnoticeable in review.

>On the other hand I DO agree that 'junior' programming will always be a problem, regardless of the matter, and pretty much, regardless of the language.

Junior developers can write a buggy mess in any language. C/C++ are practically the only popular languages where a junior developer can accidentally write a backdoor in average-looking code that doesn't use any APIs.

I can tolerate some bugs in my software sometimes, but exploitable bugs are an entirely different thing to me.

Let's say there's a trillion lines of code written in C, and a million lines of code written in the runtime for a safe language where the trust is being pushed into. That means you can throw a million times the resources at finding and fixing the bugs in the runtime. While the payoff ratio is going to be far less than linear, you're looking at the C code being buggier and problematic by 100×.

Actually, the situation for C is even worse than that makes it appear. C, both the language itself and the infrastructure ecosystem around it, actively fight you when you try to build and use tools to proactively find problems. The only tooling that tends to be effective in practice is built on dynamic analysis, which means that you can only be in confident in the safety of your code as you can be in your testing regime--and there are very few, if any, codebases that have a strong enough testing regime.

We, as an industry, have almost 50 years of coding in C. And that experience has told us that the effort it takes to build safe C code is beyond the discipline of most, if not all, development teams.

Additionally, as proven by the latest JetBrains survey, the journeyman C developer doesn't care about those tools.

> I'm sure the CVE numbers will overwhelmingly show that most RCE-capable vulnerabilities are in C/C++.

Maybe that's because most software is written in C/C++?

Compared to Java, Javascript, Python, put together?

> Compared to Java, Javascript, Python, put together?

Yes still. Look to your laptop right now and count the software running in C/C++ vs anything else. They still dominate by far.

And the current fashion of writing everything in Javascript + Electron/NodeJS, just made the C/C++ backend more important than ever. NodeJS is in C/C++, V8 is in C++, Chromium is in C++, Firefox is in C++/Rust and every library behind are in C.

So lets us constrain to the Linux kernel, with its patch review process, ksan and static analysis tooling.

As per Google talk at Linux Kernel Summit 2018, 68% of Linux kernel exploits are caused by C's lack of safety against memory corruption, in spite of all the tools and processes they have in place.

Hence, the Kernel Self Protection Project sponsored by Google.

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

Even if you corrected for that, I would still expect this to be true. A potential RCE in C/C++ is literally as easy as writing past the end of an array or writing to a pointer to something that's already been freed. Few other languages give such huge consequences to minor mistakes in average code.

The arguments that C/C++ are just as safe as other languages and that's it's just a matter of opinion or experience are unfounded. It's like saying a minefield is just as safe as anywhere else to walk because you can randomly suddenly die anywhere else too because of stuff like strokes or heart attacks. You just gotta have good landmine senses and it's your own fault if you can't avoid them.

This is certainly not the case. Line-for-line I'm sure that most software is written in Javascript.

> I'm sure the CVE numbers will overwhelmingly show that most RCE-capable vulnerabilities are in C/C++.

This is where it is critical to differenciate C and C++.

https://jaxenter.com/security-vulnerabilities-languages-1570...

> Total reported open source vulnerabilities per language:

> C (46.9%)

> PHP (16.7%)

> Java (11.4%)

> JavaScript (10.2%)

> Python (5.45%)

> C++ (5.23%)

> Ruby (4.25%)

I would like to see those stats divided by total SLOC in all projects for each language. C might top the list simply because there's a lot of C projects in the dataset.

Well, Morris Worm is now 30 years old and C CVEs due to memory corruption bugs have kept a stendy growth since then.

Amen, brother! But i would add C++ too (with reservations on the "easy" part); to me they go together. In one of my previous posts i had mentioned the advantages of C, two of which are worth listing here.

a) C allows you to program "everything"; from big honking servers (backend and frontend), networking protocols and systems etc. and all the way down to itty-bitty 8-bit MCUs. Basically from above assembly to any sort of application you might care about.

b) C is the de-facto "glue" language to everything i.e. the "assembly" of high-level languages. Almost all languages allow you to link to a C module.

I am often mystified when people say C is "hard" when they program in languages like Java/Python/Javascript etc. To me these languages are baroque and hard since they require more mental effort to memorize and use the bazillion frameworks, libraries, objects and methods. I find them all quite overwhelming.

> Almost all languages allow you to link to a C module.

no, almost all languages allow you to call into your operating system's native dynamic library format.

That this binary was originally built with C, C++ in extern "C", fortran, ADA, D -betterC, Pascal... does not matter at all.

C just happens to be the most popular language for building those...

>That this binary was originally built with C, C++ in extern "C", fortran, ADA, D -betterC, Pascal... does not matter at all.

Not quite; the point of using the phrase "link to a C module" was to point out that all of them conform to the applicable "C ABI" for a platform and therein lies C's strength as a "glue" language.

C does not have an ABI in itself, it just uses the conventions of its host system.

e.g. how function calls are done, how names are mangled (for instance on macOS all function names are prepended with an underscore and not on 64-bit windows nor linux...), etc... none of this is defined in the C standard, and it varies across platforms.

>the applicable "C ABI" for a platform

Was the phrase i used. It is well known that the C standard does not define an ABI but a processor arch+OS i.e. platform defines it. Over time that defined for C binaries on a platform have become the "de facto" standard and almost all other language run-times hew to it as needed.

> I am often mystified when people say C is "hard"

Here are some examples of why people say C is hard:

https://pzemtsov.github.io/2016/11/06/bug-story-alignment-on...

https://blog.regehr.org/archives/1520

https://www.imperialviolet.org/2016/06/26/nonnull.html

> C does work pretty well

The GCC team thinks differently, since GCC moved to C++ [1]

[1] https://lwn.net/Articles/542457/

Improvements in tooling like address sanitizer, valgrind, afl also help a lot in improving code quality, especially if you make them part of your CI. However it should possible to have a language that gives you both the speed and safety guarantees. There are many languages that contend for that category: Go (not on speed though), Rust, etc. Might be worth looking at some of the Rust projects like ripgrep that are really focused on performance and faster than C implementations like grep.

Go would never replace C because of speed and lack of direct memory access. Rust syntax is very ugly, Rust is more complex than C and harder to read. is very simple.

Go can do the same direct memory access as C does via unsafe.Pointer.

If you mean real hardware access, not even C can do that unless it is running bare metal without an underlying OS or MMU controlling the access, both situation outside of ISO C specification.

I wouldn't say baremetal is more outside of spec than MMU/ OS virtual memory is outside of spec.