GNU Coding Standards: Writing Robust Programs
1–10 of 111 posts
Re: GNU Coding Standards: Writing Robust Programs
#2>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.
Re: GNU Coding Standards: Writing Robust Programs
#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 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.
Re: GNU Coding Standards: Writing Robust Programs
#4I 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”.
Re: GNU Coding Standards: Writing Robust Programs
#5> 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.
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).
Re: GNU Coding Standards: Writing Robust Programs
#6> 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.
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).
Thanks.
>BUGS Very long lines are silently truncated.
And didn't know that about `mv`, good to know.
Re: GNU Coding Standards: Writing Robust Programs
#7> 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.
Some current vendor versions of awk have astonishingly short line length limitations. See e.g. (especially the latter):
https://github.com/samtools/samtools/pull/1165 https://github.com/samtools/htscodecs/pull/22
which work around limitations in the default system awk on Solaris/OpenIndiana/whatever the remnants of SunOS are called these days…
Re: GNU Coding Standards: Writing Robust Programs
#8> 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.
Just a few weeks ago, I fixed a problem in an internal tool (that still also runs on an ancient Solaris 10 box) by switching from `awk` to `gawk`, since the former would briefly whine on stderr and quit whenever a line in its input would contain too many fields. A recent change had managed to break that undocumented barrier.
In this case there's at least no silent breakage involved, but the badly written shell script that called it did not bother to check for that condition, and a fair number of heads were scratched for a while as a consequence.
Re: GNU Coding Standards: Writing Robust Programs
#9> 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…
Yep, you see it also in the split away from Qt (C++) to GTK (C).
Re: GNU Coding Standards: Writing Robust Programs
#10> 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…
> 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 that document didn't exist they would have chosen what? C++98? Java? Ada?