Yes but they have well defined and well tested places where that happens.

For example you could implement a string class in C++ using strlen, strdup etc. if you were feeling insane and it would probably be fine since you only use strdup once and then all the users of you class don't have to worry about getting it wrong.

If you write in C you have to use strdup every time you copy a string and there's no way you get it right 1000 times.

The phrase "have to" here is VM language Stockholm syndrome.

You'd be surprised how far large static buffers and snprintf will get you. Easy to deal with, no leaks, valgrind is happy...

It's pretty hard to get strdup wrong.

Yet, it happens:

https://nvd.nist.gov/vuln/detail/CVE-2017-14064

https://nvd.nist.gov/vuln/detail/CVE-2015-3182

https://nvd.nist.gov/vuln/detail/CVE-2017-13748

etc.

This is true. Although they did say "copy a string", not use strdup to copy a thing that is not a string. :)

Yes, that's one of the three CVE's I posted ;).

You got me thinking about ways one could get strdup wrong:

- input is not a string -> possible UB

- input is a string, but the character encoding wasn't what you thought -> possible UB

- input is a string, but it was the pointer-plus-length kind -> possible UB

- input is modified by another thread -> possible UB

- strdup called from within a signal handler -> possible UB

- failure to handle error return values -> possible UB

- failure to free the memory when it's no longer needed -> memory leak

- freed the memory more than once -> possible UB

- used the memory after freeing it -> possible UB

I've personally seen several of these in real-world code.

How did I forget:

- forget to #include string.h, so strdup is implicitly declared, so its return type is int, which implicitly converts to char*, so everything still compiles -> possible UB

Yes, in ways that were learned over many years, by many people. Roll some of your own crypto, while you're at it.

Why did they also wrap them in new syntax and abstraction?

Why not just build the ecosystem to do that and still have it all be “C”?

Why not some fixes to the standard and update then old but useful code, and work on better compilers?

This is what’s been confusing me for a while

If you can write safe enough C for the core of an interpreted language, why not abstract that into tools and patterns that generate better, safer C and learn how to do that over the last 30 years

Instead of JS and dozens of flavors, Python, ruby, lua...

DRY right?

My suspicion is “vanity projects generate a sense of novelty that’s easier to sell.”

But if the OS and bulk of the stack are “C inside anyway” why the extra nonsense?

The unsafe C in popular language runtimes has hopefully been written or at least reviewed by someone who knew what they were doing, and it presents a relatively controllable interface.

Most people who write code in C are not that good at avoiding memory safety issues. The process is mostly to write some code, run it, then fix it until it doesn't crash immediately anymore.

Have you ever been the first person to run valgrind on a codebase? Lots of uninitialized reads and use-after-free issues will be flagged, because they don't normally crash the program and therefore go undetected without using an additional checker.

It can be fun to watch the error messages flow by, until you realize that now you have to file tickets for all of them. And some people won't even see the problem with those errors that don't crash the program, because potentially exploitable vulnerabilities are not as obviously bad as crashes.

I agree, but this does not mean that some experienced developers can't have some fun creating some tools in C, they may even be less buggy and more performant then some of the other tools written in high level languages.

Btw, I am not a C fan, in fact I think I have no favorite language, I use what I have to for the project

This isn't about cool this is about dangerous. C makes shooting yourself in the foot so easy and efficient it even asks for artillery support.

The time and effort to secure a C program against malicious input is absolutely huge. It would be quicker to write a secure dsl that using raw C. Which brings us back to scripting languages that have that implemented already as a library you load to run your requests through.

C lovers are downvoting you but you're entirely right.

Most of the string manipulation and memory management happens in the safe high level languages in such cases.

> And those c programs call binary files.

Uh... am I missing the joke? The C programs don't "call binary files", the C programs become the binary files through compilation.