3 ms·

> C is incredibly easy to grok. what does this mean, though? writing good, secure C is so hard that literally no one can do it at scale. not Linus, not Theo,

> C is incredibly easy to grok. what does this mean, though? writing good, secure C is so hard that literally no one can do it at scale. not Linus, not Theo, not even djb. why do you find "learning enough to write bad code isn't very hard" to be valuable? I'm not even really convinced that C is that useful as an approximation of "how computers work" anymore - caches and NUMA and speculative execution and mmap and large numbers of varying ability cpu cores and asynchronous code make C more of an approximation of "how the PDP worked in the 1970s" (with an abstraction layer that is an endless rolling nightmare of critical security issues), which I guess is a bit useful, but not as the thing we base the world on. and a C with array bounds checking and length-prefix strings would still have a shitty type system and no meta programming and not even an iteration protocol (or ability to add a nice one). > Remind me again why we can't use Pascal? I would guess it's because Unix-alikes (and for a while Windows, though I guess it had less C and more C++ earlier) ate the world and using the language (almost all of) the OS was written in had huge network effects.

stefan_ 3y ago
The efforts of language nerds to make ever more convoluted syntax really has nothing to do with the safety and security of code. Hence C#, Python et al.
- actionfromafar 3y ago
  Not sure what you are getting at, but one class of bugs (crashing and run-foreign-code-in-memory exploit bugs) are just side-stepped in C#. On the other hand, PHP, C# and Python protects nothing against logic bugs and stuff like tripping up path validation and other things which are often exploited in other ways.
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 ago
    Glad 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 ago
  It sounds like interesting advise. Why the liberal use of structs?
  - actionfromafar 3y ago
    After 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%...

stefan_ 3y ago

The efforts of language nerds to make ever more convoluted syntax really has nothing to do with the safety and security of code. Hence C#, Python et al.

actionfromafar 3y ago
Not sure what you are getting at, but one class of bugs (crashing and run-foreign-code-in-memory exploit bugs) are just side-stepped in C#. On the other hand, PHP, C# and Python protects nothing against logic bugs and stuff like tripping up path validation and other things which are often exploited in other ways.

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 ago
  Glad 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 ago
It sounds like interesting advise. Why the liberal use of structs?
- actionfromafar 3y ago
  After 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%...