Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GNU Coding Standards: Writing Robust Programs

gnu.org

Post reply on HN
Print view View original

71–80 of 111 posts

Re: GNU Coding Standards: Writing Robust Programs

#71

Post by jcranmer »

quasit1 wrote: post #25
pjmlp wrote: post #3

> 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 environ…

I've spent 10 years writing security critical C code. There's no problem writing secure code in C. You just have to stop being clever and prioritize security above "speed". Your code will probably be fast enough anyway. If it's too slow, then you probably have an issue with which algorithm/data structure you chose and would have had the same issue in another language. The biggest issue I have with C today is that you…

> having optimizations off is not an option either, since it can generate broken code as well, so...

Especially when you add this line, you're telling me that what you want is not to program in C but to program in a language which differs from C not in syntax but in semantics, and in otherwise vaguely undefined terms [1] there. And you're mad that compilers implement C instead of your not-C.

I find claims that you can safely write secure code in C hard to believe when you marry them with complaints about compilers not implementing not-C correctly. Especially given that virtually every new sanitizer and static analysis tool to find issues in C code manages to turn up issues in code that is rigorously tested to make sure it passes every known prior tool (e.g., SQLite).

[1] From prior experience, this tends to be best distilled as "the compiler must read the programmer's mind."

Re: GNU Coding Standards: Writing Robust Programs

#72

Post by yjftsjthsd-h »

pjmlp wrote: post #40
cng100 wrote: post #13

Earlier quoted context omitted.

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

Right, https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...

If you want to play that game, https://www.cvedetails.com/product/32238/Microsoft-Windows-1... shows Windows, indeed, having more CVEs, in spite of, AFAIK, not using C (substantially, at least). Of course, the real problem is that CVE counts may or may not mean anything when comparing systems with wildly different development models (FOSS/proprietary) used mostly in different areas (desktop / everything else).

Re: GNU Coding Standards: Writing Robust Programs

#73

Post by morelisp »

enriquto wrote: post #65
junon wrote: post #54

Earlier quoted context omitted.

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

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

Nah, "utterly unreadable" is the right description.

Re: GNU Coding Standards: Writing Robust Programs

#74

Post by dnautics »

UncleMeat wrote: post #29
quasit1 wrote: post #25

Earlier quoted context omitted.

I've spent 10 years writing security critical C code. There's no problem writing secure code in C. You just have to stop being clever and prioritize security above "speed". Your code will probably be fast enough anyway. If it's too slow, then you probably have an issue with which algorithm/data structure you chose and would have had the same issue in another language. The biggest issue I have with C today is that you…

It is not possible to remove ub from the spec without turning everything into a pdp-11 emulator, which will sabotage performance on many platforms. I also don’t believe that a single person on the planet can write a secure c program of meaningful complexity. Static analysis tooling has demonstrated that it isn’t up to the task of saving developers from themselves.

What about SEL4?

Re: GNU Coding Standards: Writing Robust Programs

#75

Post by groby_b »

pjmlp wrote: post #12
st_goliath wrote: post #10

Earlier quoted context omitted.

> So we switched from a path where all major desktop environments ... were adopting C++ to a surge in C programming, as FOSS adoption started to gain steam. So you say FLOSS is responsible that the late 90s/early 2000s C++ hype slowly died off? > trying to fix the security inconveniences caused by this manifesto. And you believe those projects chose C, solely because some random GNU document suggested they do? If tha…

In part yes. Had GNU/Linux not taken off, in the alternative universe from Windows, BeOS, Mac OS, OS/2, commercial UNIX (remember Motif++ and CORBA?) would kept writing the software in C++, instead of caring about creating FOSS stuff in C. GNOME vs KDE is a good example of that schism and language wars.

Having written software in the 90s: C++ was unusable for large-scale apps on commodity hardware. It was a neat toy. It had humongous compile times, and the runtime was suboptimal at best.

The choice was protracted language wankery with continuous (wrong) declarations of "Soon, the compiler will make it fast enough", or actually shipping software.

The balance started tipping in the early to mid-2000s. You could, if you were very careful, write decent-sized systems with good performance in C++ at that point, and the abstractions were starting to be worth it.

And I say that as somebody who enjoys C++, and has written code in it since the late 80s. Yes, on cfront. "Horses for course" always has been, and always will be, the major driver for language adoption. That particular horse wasn't ready in the 90s.

Re: GNU Coding Standards: Writing Robust Programs

#76

Post by jandrese »

kstenerud wrote: post #42

> 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 b…

It's hard to imagine that directive lasting beyond the first bug report of "it broke, fix now!".

Re: GNU Coding Standards: Writing Robust Programs

#77

Post by groby_b »

pjmlp wrote: post #39
dvfjsdhgfv wrote: post #14

Earlier quoted context omitted.

Would you say that the predominance of C++ rather than C in FLOSS would have a net positive result?

Yes, because while it isn't fullproof due to copy-paste compatibility with C89, at least it offers better tooling for safer coding, provided one doesn't code "C with C++ compiler". Namely: - proper string and vector types (most compilers allow to enable bounds checking anyway) - stronger rules for type conversions - reference types for parameters - better tooling for immutable data structures - memory allocation prim…

A large number of those came only usefully into existence in 1998, with C++98

string & vector types: STL, 1998 type conversion operators: 1998. mutable keyword: 1998. collection library: STL, 1998. smart pointers: STL, auto_ptr in C++98

I'd argue that without STL & C++98, C++ would've languished even longer. And with STL, it still took another 5 years for the compilers to be good enough.

Re: GNU Coding Standards: Writing Robust Programs

#78

Post by plorkyeran »

bigbillheck wrote: post #4

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 a…

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

Re: GNU Coding Standards: Writing Robust Programs

#79

Post by kaba0 »

dnautics wrote: post #74
UncleMeat wrote: post #29

Earlier quoted context omitted.

It is not possible to remove ub from the spec without turning everything into a pdp-11 emulator, which will sabotage performance on many platforms. I also don’t believe that a single person on the planet can write a secure c program of meaningful complexity. Static analysis tooling has demonstrated that it isn’t up to the task of saving developers from themselves.

What about SEL4?

Written over many many years by experts of a field, and the end result is at most somewhat complex, nowhere near the complexity of even the monolith SPA of your favorite website.

Re: GNU Coding Standards: Writing Robust Programs

#80

Post by posix_me_less »

dnautics wrote: post #74
UncleMeat wrote: post #29

Earlier quoted context omitted.

It is not possible to remove ub from the spec without turning everything into a pdp-11 emulator, which will sabotage performance on many platforms. I also don’t believe that a single person on the planet can write a secure c program of meaningful complexity. Static analysis tooling has demonstrated that it isn’t up to the task of saving developers from themselves.

What about SEL4?

The speed of development was very low, and how many people can check the proofs?
Post reply on HN