https://github.com/antirez/sds
Naturally turning on all security features of the C compiler being used, warnings, warnings as errors, static analysers, FORTIFY like libraries, the whole package.
And like almost everyone else, I end up having my occasional segfault regardless of the amount of precautions taken, because I am not elite enough.
- 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.
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.
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.
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.
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.
> 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.
I'd argue doing it globally but as warning would be a better alternative than doing it file by file.
extern void banned() __attribute__((deprecated("This function is problematic")));
#define strcpy(...) strcpy(__VA_ARGS__); banned;
test.c:11:3: warning: 'banned' is deprecated: This function is problematic [-Wdeprecated-declarations]
strcpy(x, y);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 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.
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 not?
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.
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.
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.
C is a sharp knife with no handle; this is it's purpose as a language and tool.
cc: theo@openbsd.org
Yes, they should. Or several other things depending on what exactly they need.
> C is a sharp knife with no handle; this is it's purpose as a language and tool.
Help me out here HN resident survivalists, carpenters, maybe circus knife throwers. What is the "purpose" of a "sharp knife with no handle" exactly? How often have you thought, "Man, it'd be so much easier to gather firewood, carve decorations or score a bullseye if only the blade would sink into my own flesh while I was using it because it doesn't have a handle" ?
Historically the argument was, "We're using C because alternatives like Java or Python or whatever aren't fast enough or capable enough". OK. But, somewhere in the last few years it moved to, "We're using C because alternatives aren't dangerous enough" and that's crazy.
The purpose is not to assume what the developer wants, but provide access to all the resources(and manipulation) they need.
If you need guardrails there are 10s of languages designed for specific purposes.
You should use a knife that comes with such a handle but gives you the option to take it off when you want to impress your friends with your knife-juggling skills and feel you have a few fingers too many.
C lacks a handle because its designers didn't care to provide one, it is after all based on a language whose main purpose was to Bootstrap CPL.