I hate that formatting style personally.
> 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
GNU Coding Standards: Writing Robust Programs
31–40 of 111 posts
Re: GNU Coding Standards: Writing Robust Programs
#32Earlier quoted context omitted.
I can't speak for the parent, but I've been using RAII and smart pointers in the 00s and it provided a lot of the benefits that got standardised with C++11.
None of that was a thing in 90s and early 00s.
RAII and smart pointers definitely were a thing in the 90s. I wrote lots of COM code using these techniques. According to wikipedia, RAII was invented in 1984-89.
Re: GNU Coding Standards: Writing Robust Programs
#33Earlier quoted context omitted.
I can't speak for the parent, but I've been using RAII and smart pointers in the 00s and it provided a lot of the benefits that got standardised with C++11.
None of that was a thing in 90s and early 00s.
auto_ptr (precursor to unique_ptr) was first proposed for standardisation in 1994 [0], and there was probably non standard versions of it before 94.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1994/N055...
Re: GNU Coding Standards: Writing Robust Programs
#34Earlier quoted context omitted.
None of that was a thing in 90s and early 00s.
The average C++ codebase isn't from the 90s. On all the recent c++ polls the average language revision used is between c++14 and 17. Besides I'm pretty confident that there are more new c++ projects created daily in 2021 than monthly at the peak of the 90s c++ craze - just on GitHub, 6/7% of C++ repos means a few million recent C++ repos.
I've worked on several code bases that nominally are C++11 or 14. However they still contain a lot of code written by people still coding like it's the 90s.
Re: GNU Coding Standards: Writing Robust Programs
#35Always 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.
Re: GNU Coding Standards: Writing Robust Programs
#36Earlier 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…
Which checks will the compiler remove? If you haven't invoked undefined behaviour then that should be a bug in the compiler
They might be thinking of cases like where C compilers can remove code that zeroes memory holding security-sensitive data. [0][1] The compiler is permitted to reason that this memory is about to be deallocated anyway, so we can elide the memset call.
I can't imagine why a C compiler would remove a non-trivial runtime check though (except undefined behaviour).
[0] https://wiki.sei.cmu.edu/confluence/display/c/MSC06-C.+Bewar...
Re: GNU Coding Standards: Writing Robust Programs
#37Earlier quoted context omitted.
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.
All of those operating systems kernels were written in C (and ASM) not C++.
Where did I mentioned the kernel?
And no, that is not correct.
Mac OS was a mix of Object Pascal (originally created by Apple), Assembly and C++.
Windows (32 bit variants) and OS/2 userspace has always been a mix of C and C++.
BeOS userspace was C++.
Symbian was full C++, including the kernel by the way.
Re: GNU Coding Standards: Writing Robust Programs
#38I 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…
GNU has always had that childish tinge to its writings. Chief GNUsance and all that.
Re: GNU Coding Standards: Writing Robust Programs
#39Earlier quoted context omitted.
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.
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 primitives instead of getting sizeof wrong to malloc()
- collection library instead of reinventing the wheel in each project
- RAII
- smart pointers
- templates instead of error prone macros
- namespacing (usefull in large scale projects with prefix tricks)
Re: GNU Coding Standards: Writing Robust Programs
#40> 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…
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.