GNU Coding Standards: Writing Robust Programs
81–90 of 111 posts
Re: GNU Coding Standards: Writing Robust Programs
#82Earlier quoted context omitted.
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.
> On all the recent c++ polls the average language revision used is between c++14 and 17. Polls of hobbyist coders, or software houses? I would be surprised if most software houses migrated to C++17 yet. Tensorflow is stuck on C++03 I think.
I'm referring to e.g. the Jetbrains and cppcon polls.
Re: GNU Coding Standards: Writing Robust Programs
#83Earlier quoted context omitted.
Old versions of 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).
mv doesn’t do that anymore. Is there any reason to use cp and rm instead of mv today?
Re: GNU Coding Standards: Writing Robust Programs
#84Re: GNU Coding Standards: Writing Robust Programs
#85> 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.
> 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.
Re: GNU Coding Standards: Writing Robust Programs
#86Earlier quoted context omitted.
What about SEL4?
The speed of development was very low, and how many people can check the proofs?
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
Re: GNU Coding Standards: Writing Robust Programs
#87Earlier quoted context omitted.
> On all the recent c++ polls the average language revision used is between c++14 and 17. Polls of hobbyist coders, or software houses? I would be surprised if most software houses migrated to C++17 yet. Tensorflow is stuck on C++03 I think.
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
Re: GNU Coding Standards: Writing Robust Programs
#88Earlier quoted context omitted.
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.
> meaningful complexity
Not, "the most complex". If an OS that can lock down DARPA self-flying helicopter software is not meaningful enough for you....
Re: GNU Coding Standards: Writing Robust Programs
#89Earlier quoted context omitted.
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.
GP said: > meaningful complexity Not, "the most complex". If an OS that can lock down DARPA self-flying helicopter software is not meaningful enough for you....
Re: GNU Coding Standards: Writing Robust Programs
#90Earlier quoted context omitted.
GP said: > meaningful complexity Not, "the most complex". If an OS that can lock down DARPA self-flying helicopter software is not meaningful enough for you....
Less than 10 000 lines of code. But let’s say we accept it as an exception — it is most definitely not the “standard way” of writing C programs.
> It is not possible to remove ub from the spec
did not say "it is not standard to remove ub"...