Hacker News Reader

Comment by Someone1234 | Hacker News Reader

I like it too, but then you're going down the uncanny valley of:

- The project is new, in which case you can easily/safely ban functions, but then why are you starting a new C project in 2021?

- The project already exists, and now you need to refactor out all the compile-time errors in order to move forward (time-consuming).

Keep in mind the first is a real question that should be answered. If your goal is to avoid undefined behavior/potential security headaches, then C should be entered into after careful consideration of cost/benefits. There are better alternatives for some projects but not others YMMV.

View on HN

> The project is new, in which case you can safely ban functions, but then why are you starting a new C project in 2021?

Interoperability? A tons of chips have a single C compiler forked from an old version of GCC without even full C99 support and that's it. Good luck getting anything else running on that hardware.

That's why you should evaluate the cost/benefit, like I said.

> If your goal is to avoid undefined behavior/potential security headaches, then C should be entered into after careful consideration of cost/benefits. There are better alternatives for some projects but not others YMMV.

Yep, for the 0.0001% of developers who target arcane architectures C is still pretty much it.

One reason would be because you heard about Azure Sphere, their security marketing, and the 7 properties of highly secure platforms, so you order a devkit.

Then when you open the box you discover that despite all the security talk, the only way to officially program the Azure Sphere is with a C SDK.

> - The project already exists, and now you need to refactor out all the compile-time errors in order to move forward (time-consuming).

Use a static analysis tool with proper, non-brittle tracking of new vs old findings (including proper move and copy file tracking) and forbid new findings, e.g. by preventing offending code from being merged to master with tools like Gitlab, Bitbucket, what have you. Works very well in practice. Bonus points if the tool can also tell you when you modified a function and didn't clean up the old findings in there. Then you can really enforce incremental improvement.

Disclaimer: I work on Teamscale (https://teamscale.com), which does all that.

Both cases are real. If you start a new project in C, it means you have a very good reason - and hopefully a strategy of dealing with strings and other problematic issues.

If you need to deal with an older codebase, the all-or-nothing approach might not be appropriate - incremental improvements might be a better option. Yes, you will have more problems to deal with initially, but with time the situation will get better.

> If you start a new project in C, it means you have a very good reason

That does not follow.

If you do it, you ought to have a good reason, but very probably don't. Any reason you thought you had, if you had any at all, argues for C++ instead, because it works anywhere C does, and enables you to choose to use modern methods that are not inherently error-prone.

Whether you do choose to use modern methods, in any non-C language you end up using, is a whole other matter. But at least you can.

There are still platforms with C compilers but no (or very bad) C++ compilers. It's much easier to write a decent C compiler than a C++ one.

Yeah. If you want your code to “just work” on stuff like the BSDs, then C (or an interpreter written in C) is still your best bet.

The set of such platforms that one might start a new project for is very limited. Maybe, flight computer in a Boeing 737 variant? Betting that has no C compiler. 8051?

The BSDs have supported C++ user-space programs for long enough that "just working" should be well within range.

A new project involving a BSD or Linux kernel subsystem, or PostgreSQL or SQLite component, is a plausible interpretation, where C++ is actually forbidden for wholly non-technical reasons.

We use C because significant parts of our platform are GStreamer plugins… so C. Though if I were going to greenfield GStreamer C would still be a pretty reasonable option in 2021 IMO.

You can have reasonable C FFI from several other languages. Notably in this context Rust.

Of course if your code is just a thin layer of glue it's not worth it, you'd spend all your time getting into and out of the FFI. But if you write a non-trivial amount of code that actually does something because it isn't just a glue layer, C might actually not be the obvious choice after all.

In the particular case of Rust, somebody else apparently already did this work (not tested, and thus not vouched for): https://crates.io/crates/gstreamer

GStreamer plugins do not in any way dictate C. C++ works fine. As does Zig; and even Rust, with some annoyance.

> Though if I were going to greenfield GStreamer C would still be a pretty reasonable option in 2021 IMO.

GStreamer is routinely exposed to hostile content in non-sandboxed contexts, such as your traditional Linux desktop; it even works as a browser plugin! Among projects you might want to write in C, GStreamer strikes me as one of the least reasonable. If GStreamer were more widely deployed on phones, it'd be prime attack surface for e.g. regimes attempting to surveil journalists.

"Yeah, but it's not that bad, because like, you can always choose not install the gstreamer-plugins-ugly package."

>We use C because significant parts of our platform are GStreamer plugins… so C.

Ehh..., we have written and deployed gstreamer plugins for a proprietary project at $dayjob which was written in Rust. In the case of gstreamer, they have a plethora of examples for their Rust bindings (I think it's also officially supported).

> why are you starting a new C project in 2021?

Why not?

It's unsafe.

And what is safe? C has well defined, tested, and documented specifications which layout exactly how to use C safely. Languages like Rust are more safe but nothing is just safe. If you are an inexperienced developer it is still very easy to write insecure code in Rust.

Sure, moving to safer languages is good. But it is impossible to rule out the use of a language so established that every major operating system is written in it. It is practically impossible to not use C - safe languages are normally bootstrapped by it and eventually your “safe” code will run in an environment programmed in C.

I agree that nothing is fully safe and any developer will alway introduce security vulnerabilities eventually, but history has proven than C is unsafe and generations of very competent developers wrote unsafe C despite documentation to write C safely.

It's pretty fun though. Despite all the problems, I just don't enjoy programming in other languages as much as I enjoy writing C. I've tried C++, Rust, Go, Zig, Javascript, Ruby, Python, Lisp, Lua... I just don't feel as free as I do while writing C.

The ban can be rolled out gradually by not including banned.h everywhere.

But then you're undermining your own hard compile time check, wherein specific files or areas of the project could fall through the cracks and continue to used supposedly "banned" functions.

I'd argue doing it globally but as warning would be a better alternative than doing it file by file.

A warning would be nice, is there a way to implement that without changing the compiler though?

Something along these lines should work, for at least both of GCC and Clang:

    extern void banned() __attribute__((deprecated("This function is problematic")));

    #define strcpy(...) strcpy(__VA_ARGS__); banned;

Which would output something along the lines of:

    test.c:11:3: warning: 'banned' is deprecated: This function is problematic [-Wdeprecated-declarations]
  strcpy(x, y);

MSVC does this, or at least did the last time I had to compile C code for windows. You should be able to do it with the preprocessor if you wanted to.

Reply on news.ycombinator.com