10 ms·
GNU Coding Standards: Writing Robust Programs
- asicsp 5y ago>In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility. Would be interested to know examples for this.
- bigbillheck 5y agoOld versions of sort: http://man.cat-v.org/unix_7th/1/sort http://man.cat-v.org/unix_7th/1/sort Unix utilities in the old days weren't all that great. One example I've posted about here before is how mv would refuse to move files across filesystem boundaries (because it's not a 'move', it's a 'copy and delete', so you had to use cp and rm instead).
- jomar 5y agoSome current vendor versions of awk have astonishingly short line length limitations. See e.g. (especially the latter): https://github.com/samtools/samtools/pull/1165 https://github.com/samtools/samtools/pull/1165 https://github.com/samtools/htscodecs/pull/22 https://github.com/samtools/htscodecs/pull/22 which work around limitations in the default system awk on Solaris/OpenIndiana/whatever the remnants of SunOS are called these days…
- c0l0 5y agoJust a few weeks ago, I fixed a problem in an internal tool (that still also runs on an ancient Solaris 10 box) by switching from `awk` to `gawk`, since the former would briefly whine on stderr and quit whenever a line in its input would contain too many fields. A recent change had managed to break that undocumented barrier. In this case there's at least no silent breakage involved, but the badly written shell script that called it did not bother to check for that condition, and a fair number of heads were scratched for a while as a consequence.
- andylynch 5y agoYep. When we did Solaris installs GNU coreutils and friends were high on the list. Incidentally nice to see sunfreeware.com is still going!
- astrobe_ 5y agoThe whole paragraph: > Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility. ... goes against MISRA C, which certainly is preferable in the domain I work, embedded systems - because dynamic allocations all over the place are a recipe for CVEs.
- jcelerier 5y agoGNU is about making software for the end-user, that's the opposite of what MISRA is about
- astrobe_ 5y agohttps://www.cvedetails.com/vulnerability-list/vendor_id-72/GNU.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/G... A significant number of these CVEs are related to dynamic memory allocation (double-free, use-after-free). Probably not all are the result of that piece of advice and probably some of those memory allocations were necessary, but since this class of errors is common in C/C++, I believe it is really not a good idea to encourage people to point the gun right to their feet. On a side note, please explain to me how this is end-user oriented in a system where the convention is that a program ends silently when everything went smoothly: > In error checks that detect “impossible” conditions, just abort. There is usually no point in printing any message [...] Explain the problem with comments in the source.
- jcelerier 5y agoif everything went smoothly likely the program had some useful output (e.g. grep, awk, sed). If it failed then I'd just run `coredumpctl gdb` ? (and ... abort isn't silent ? here's what I get if something aborts here: https://imgur.com/a/69eF73w https://imgur.com/a/69eF73w)
- pjmlp 5y ago> When you want to use a language that gets compiled and runs at high speed, the best language to use is C. C++ is ok too, but please don’t make heavy use of templates. So is Java, if you compile it. Back in the early days, this sentence was more like "When you want to use a language that gets compiled and runs at high speed, the best language to use is C.". So we switched from a path where all major desktop environments (OS/2, Mac, Windows, UNIX) were adopting C++ to a surge in C programming, as FOSS adoption started to gain steam. So here we are now, about 30 years later, trying to fix the security inconveniences caused by this manifesto.
- cng100 5y agoThe average C++ code base has as many segfaults than the average C code base. Windows has more exploits than Linux. But you know all that, so I wonder why you keep making these statements, which are then upvoted by the "memory-safe" crowd.
- krychu 5y agoI’m glad this doesn’t go unnoticed, and share the observation. There seem to be quite some effort going into creating illusions of truth about C. Just a personal observation.
- jcelerier 5y ago> The average C++ code base has as many segfaults than the average C code base. any source for that ? I find segfaults utterly rare in C++ >= 11
- bigbillheck 5y agoI see that they still say: >>> Please don’t use “win” as an abbreviation for Microsoft Windows in GNU software or documentation. In hacker terminology, calling something a “win” is a form of praise. You’re free to praise Microsoft Windows on your own if you want, but please don’t do so in GNU packages. Please write “Windows” in full, or abbreviate it to “w.” But they have removed some other guidance: >>> Instead of abbreviating “Windows” to “un”, you can write it in full or abbreviate it to “woe” or “w”.
- Joker_vD 5y agoFree as in "free speech", yes.
- na85 5y agoGNU has always had that childish tinge to its writings. Chief GNUsance and all that.
- junon 5y agoThis is exactly why I've never been on the GNU-train. The radicality of RMS's writings and philosophies paired with the subtle condescending and childish tone in all of the guides, licenses, articles, blog posts, etc.
- plorkyeran 5y agoEncountering "woe32" in GNU things was what made me stop writing M$ as a teen. It was so embarrassingly petty that it made me entirely reconsider the idea of insulting nicknames for things I don't like.
- abakus 5y agoI find the coding standard too long to be taken seriously.
- sigzero 5y agoI hate that formatting style personally.
- pentagone 5y ago> First off, I’d suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it’s a great symbolic gesture. - The doc on Linux kernel coding style
- junon 5y agoMe too. I've never understood it. I just went back through the clang-format documentation and looked at some of the examples for the GNU style and was reminded at how utterly unreadable the resulting code is.
- enriquto 5y agoThe rationale for this style seems to be to make it appealing to Lisp programmers, which will find it familiar. I also dislike it for C (as much as I appreciate GNU's contribution). As we all know, K&R is the one true style.
- wirrbel 5y agoI never worked in a codebase that was formatted in this style and surely its weird and not at all what I am used to. But I somehow from looking at the examples find it to be somewhat pleasant. Doesn't mean I would pick it as my standard but I can see how one could. I do prefer putting opening braces at the line end in all situations though (but that also rules out a lot of other styles).
- jjice 5y agoAlways interesting to see standards across different groups. The kernel is also very interesting, being very strict and having reasoning that not all may agree with, but has proved to work well. I think C is a beast for standard in general due to it's rogue history. Now when a language like Rust or Go is created, standards are released with the code via formatting tools that enforce consistency (which I'm all for). The amount of time I've seen C code with inconsistencies within a single file (naming, spacing, you name it) from fellow students back when I was in college was insane. Enforced code style standards are great, even if I don't agree with them. Go's public vs private distinction is a good example. I really am not a huge fan of the pascal vs camel case to denote private and public (it's grown on me a bit, but still not a fan), but I know their code is going to be reasonable (in looks) because Go is very picky about how the code looks.
- kstenerud 5y ago> In error checks that detect “impossible” conditions, just abort. There is usually no point in printing any message. These checks indicate the existence of bugs. Whoever wants to fix the bugs will have to read the source code and run a debugger. So explain the problem with comments in the source. But then the person RUNNING the program will only see this: Abort trap: 6 And that's all the info you'll get from their bug report. So please ignore this directive and print a descriptive message always, complete with file and line, and the values that led to the impossible situation. Then you can get helpful bug reports like: BUG: flush.c:51: buff_offset (65535) must not be greater than 20! Abort trap: 6
- jandrese 5y agoIt's hard to imagine that directive lasting beyond the first bug report of "it broke, fix now!".
- feffe 5y agoThe core dump contains information for fault analysis. There is another aspect, C and C++ are not memory safe languages so the bug may not be particular logical (i.e. some kind of memory corruption). In these cases I actually prefer something to the like of __builtin_trap instead of abort. Calling any code after an invalid invariant has been detected clobbers registers and may make it impossible to investigate the state at the time of the "crash". Some features of modern optimizing compilers make this even worse, such as abort being marked as "noreturn".
- deleted 5y ago[deleted]
- musicale 5y agoHow about "always use gcc/g++ in memory-safe compilation mode?" I'd like to be able to type something like: gcc -march=x86-64-safe my_buggy_server.c Come to think of it, that should probably be the default.