Principles for C programming
I disagree with quite a few of them. The title should be &quot;Principle for C programming ON UNUX BASED SYSTEMS&quot;. C programming is quite a bit wider that this, and some of the typical points here are no-no if you want to write &#x2F;portable&#x2F; C.<p>For example, &quot;Do not use fixed size buffers&quot;. It&#x27;s all very fine, but 1) it can be exploited <i>as well</i> if someone managed to fudge the size you are going to allocate, and 2) on some platform, you don&#x27;t have&#x2F;want malloc(). So it&#x27;s a lot better to have a fixed buffer <i>and check the sizes carefully</i> before copying into it.<p>Another one I dislike (but it&#x27;s personal preference) is the &#x27;use struct for pointers to structs&#x27; -- well, nope, I don&#x27;t like that, it&#x27;s unnecessarily heavy. I typedef my structs all the time, and call them something_t, and * something_p. It&#x27;s easier to rework, rename, search for and it&#x27;s quicker to type so makes the source code lighter to read. I <i>know</i> it&#x27;s not popular, and for example the kernel guidelines agree with you, but I don&#x27;t.<p>As for &quot;no circumstances should you ever use gcc extensions or glibc extensions&quot; well sorry, I also disagree here. I love the &#x27;case X..Y:&#x27; syntax for example and it&#x27;s been around for about a million years. It&#x27;s not because the C standards prefer adding idiotic syntax instead of <i>useful ones</i> like this that I&#x27;m going to stick along and limp when there is a perfectly nice, clear and very readable alternative.<p>Another one I <i>love</i> but can&#x27;t use are the sub-functions. Now <i>what also</i> would have been a lovely extension if the runtime had been perfected a bit, but it was never &#x27;finished&#x27;. Speak of easier code to read when your qsort() callback is listed &#x2F;just above&#x2F; the call to qsort().<p>Another extension is of course the __builtins that you actually do need on modern systems. Like memory barriers, compare and swaps, ffs, popcount and so on. Of <i>course</i> I can have an explicit function to do it (in the case of the last 2), but that&#x27;s the sort of things that <i>ought</i> to be in the C library anyway. So I&#x27;ll use these, thanks.<p>As far as the rest of the article about the process, your code reviewers and so on, in many places and on many projects (open source ones are a case in point) you don&#x27;t have the freedom&#x2F;time to do that. The rule is &#x27; do as best as you can&#x27; -- and that <i>ought</i> to do it in many cases.