from Hacker News

GNU Coding Standards: Writing Robust Programs

by mpsq on 6/10/21, 10:46 AM with 109 comments

  • by kstenerud on 6/11/21, 2:17 PM

    > 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

  • by pjmlp on 6/10/21, 11:45 AM

    > 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.

  • by bigbillheck on 6/10/21, 12:40 PM

    I 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”.

  • by jjice on 6/11/21, 1:22 PM

    Always 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.

  • by asicsp on 6/10/21, 11:32 AM

    >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.

  • by sigzero on 6/11/21, 12:46 PM

    I hate that formatting style personally.

  • by musicale on 6/11/21, 10:08 PM

    How 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.

  • by abakus on 6/11/21, 5:24 PM

    I find the coding standard too long to be taken seriously.