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

91–100 of 111 posts

Re: GNU Coding Standards: Writing Robust Programs

#91

Post by brandmeyer »

groby_b wrote: post #77
pjmlp wrote: post #39

Earlier quoted context omitted.

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.

> And with STL, it still took another 5 years for the compilers to be good enough.

This is under-stated, IMO. It wasn't really until 2004 or even later that we had high-quality support for C++98 in GCC. LLVM wasn't available, yet. Heaven help you if you wanted to develop in C++ on OSX, since Apple's packaging of GCC was a total disaster. Step zero for developing C++ on OSX was "install GCC from FSF sources" for many years.

Even MSVC support was lagging. It wasn't until the Microsoft tools leadership got involved with C++11 that MSVC took standard support seriously. They were already prioritizing .NET in that timeframe.

Meanwhile, the big open-source desktop C++ libraries (Qt and WxWindows) still don't fully take advantage of the types and features in the standard library in 2021.

Re: GNU Coding Standards: Writing Robust Programs

#92

Post by touisteur »

prpl wrote: post #66
mcguire wrote: post #59

Earlier quoted context omitted.

You ever used auto_ptr? In 1992, I was working on the Taligent project, probably the first major C++ operating system. (It failed.) I remember when the ARM came out---none of the compilers we had available could really do templates. Or namespaces.

A part of Taligent lives on with ROOT, which was very annoying.

Oh no... ROOT. It's a testament to the pure grit and gumption or thousands of poor undergraduates that particle physics can advance, with this. Eons ago, I tried several times to help my then-girlfriend (you know how it goes 'hey you have some kind of eng diploma'? Yes sw engineering... - Hu so you know C++? - nobody 'knows' C++ but I can manage 'so here what I'm trying to do, here are 3 other examples, please for the love of Wotan help') and I was baffled on how to do anything with it. I mean the core thing seems powerful enough, but trying to go out of the beaten path (research, right ?) was yugely frustrating... And I'd worked on 2 physics codebases or variable quality before. I didn't appear as competent as I'd hoped and spent so much time helping, reading docs and code without understanding much of the design. This is the codebase that started my deep defiance for OOP and especially OOP-as-a-mirror-of-the-real-world and inheritance-for-code-economy...

Re: GNU Coding Standards: Writing Robust Programs

#93

Post by jcelerier »

secondcoming wrote: post #87
jcelerier wrote: post #82

Earlier quoted context omitted.

TF is at least C++11 from the first header I opened in the repo: https://github.com/tensorflow/tensorflow/blob/master/tensorf... I'm referring to e.g. the Jetbrains and cppcon polls. https://blog.jetbrains.com/clion/2020/06/dev-eco-cpp-2020/ https://youtu.be/JYzDpXI-vWI?t=137

Last time I used it there was faff around having to define __GLIBCXX_USE_CXX11_ABI=0

it does not mean that you're not using C++11. This macro is just a compatibility flag for your code to work on old linux distros that provide a C++11 compiler but did not want to rebuild their whole archive. It mainly means that std::string is implemented with copy-on-write instead of small buffer optimization.

Re: GNU Coding Standards: Writing Robust Programs

#94

Post by UncleMeat »

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?

I've got a strong background in formal verification. I do not believe that "formally verified" means "security bug free". In fact, I personally know researchers who have had vulns found in their formally verified code more than a decade after they completed the verification.

Re: GNU Coding Standards: Writing Robust Programs

#95

Post by wirrbel »

sigzero wrote: post #27

I hate that formatting style personally.

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

Re: GNU Coding Standards: Writing Robust Programs

#96

Post by duskwuff »

pjmlp wrote: post #37
CraigJPerry wrote: post #16

Earlier quoted context omitted.

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.

> Mac OS was a mix of Object Pascal (originally created by Apple), Assembly and C++.

That doesn't ring true at all.

Object Pascal was a rather short-lived project at Apple. It was only seriously used for the MacApp framework -- which was a separate product sold to application developers, not part of the core OS or development tools -- and was abandoned entirely during the PowerPC transition. Later versions of MacApp used C++.

The bits of source code I've seen for System 7 were primarily C and assembly, with some older code in (non-object) Pascal. I don't recall seeing any C++.

Re: GNU Coding Standards: Writing Robust Programs

#97

Post by dnautics »

UncleMeat wrote: post #94
dnautics wrote: post #74

Earlier quoted context omitted.

What about SEL4?

I've got a strong background in formal verification. I do not believe that "formally verified" means "security bug free". In fact, I personally know researchers who have had vulns found in their formally verified code more than a decade after they completed the verification.

I don't think there is any reasonable standard of security that demands perfection.

Re: GNU Coding Standards: Writing Robust Programs

#98

Post by oscardssmith »

dnautics wrote: post #86
posix_me_less wrote: post #80

Earlier quoted context omitted.

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

> The speed of development was very low, Not a part of GP's assertion > and how many people can check the proofs? it's not necessary, the proofs are checked using automation. I'm directly taking a shot at this assertion: > Static analysis tooling has demonstrated that it isn’t up to the task

Just because you have a proof doesn't mean it proves the right thing.

Re: GNU Coding Standards: Writing Robust Programs

#99

Post by zabzonk »

groby_b wrote: post #75
pjmlp wrote: post #12

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

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

> And I say that as somebody who enjoys C++, and has written code in it since the late 80s

As have I, and I say you don't seem to know what you are talking about. I've been involved in writing very large Unix and Windows applications in the 1990s (starting in the late 80s), and have had no problems that you mention.

Re: GNU Coding Standards: Writing Robust Programs

#100

Post by junon »

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.

I've not written a lot of lisp (I understand it, just never had a need for it personally) so perhaps I'm ignorant, but I don't see how it's at all similar to Lisp. It just looks different for the sake of being different.
Post reply on HN