3 ms·
Writing good, secure C is not that hard, if you are writing business code, not super optimized kernels. But it requires a discipline I only acquired by using ot
by actionfromafar 3y ago
Writing good, secure C is not that hard, if you are writing business code, not super optimized kernels. But it requires a discipline I only acquired by using other languages.
- Don't use libc string functions.
- Use a lot of structs.
- Write a lot of manipulator functions for these structs so you don't get inconsistent data.
- Write in a functional style, don't toss pointers around nilly-willy.
When you follow such self-imposed rules, it's not hard. But you find yourself writing a lot of code doing manually what a more advanced language would just do for you, out-of-the-box. And then you start questioning why you wrote it in C in the first place. (And by "you", I mean "I".)
But what I have discovered is that writing in C is so tedious, it makes me think really hard about the problem to solve so it forces me to do really the bare minimum to solve the problem, which can be a relief if you are prone to over-thinking code and architecture. In C# with an IDE it's so easy to just throw in some abstractions and options and what-not "just in case" which would be a right pain in C.
- bananapub 3y ago> When you follow such self-imposed rules, it's not hard. this is an extremely funny reply, thanks.
- actionfromafar 3y agoGlad to be of at least amusement. :-D Edit: I think C is easy like the game of Chess. The rules are easy to grok...
- chris_wot 3y agoIt sounds like interesting advise. Why the liberal use of structs?
- actionfromafar 3y agoAfter looking at too many char arrays with fields indexed by various #define SOMEINDEX 6, and such, I have come to this conclusion. Code like that, where the knowledge of the data structure is "sprinkled out" in lots of code with if-s and other conditionals, which all have to be updated all over the code base, should one want to change what the data structure looks like. I don't want to point fingers so I won't name names, but I took an interest in a certain file system for embedded flash because it was very good, struck a nice balance between features, size and speed, had lots of regression tests etc. In many ways a high quality product. But wow was it coded very much like that, where to read the code you had to have a full mental model of the layout on "disk" and the layout of the data structures in RAM. If it had set/get/manipulate_or_update functions operating on structs, then serializing code for the structs to disk, it would have been much easier to read. (And I don't mean heavy serializing, structs with appropriate packing instructions to the compiler would have probably sufficed.) Edit: Yet another reason to use structs, don't use naked arrays, put a size_t and the array in a struct. https://news.ycombinator.com/reply?id=39440071&goto=threads%3Fid%3Dactionfromafar%2339440071 https://news.ycombinator.com/reply?id=39440071&goto=threads%...