It seems to me that many core tools could use such updates. They're widely used yet most of them predate modern development techniques and tools such as widespread linter usage, unit tests, peer reviews before committing, appearance of various stable and portable libraries or even compilers, security scans.
I wonder what other nasty things would appear after a serious code review of the GNU and BSD core code bases.
I do agree that the code has been read probably hundreds of times and executed millions of time, but I doubt there have been many formal attempts at improvement and the overall methodoloy resembles brute forcing to me.
Most of the base system on Linuxes (which is GNU) certainly have unit tests and static analyzers run on them, to the best of my knowledge (just looked at the coreutils). Most of these programs were maintained by Cygnus, and now by Red Hat after they acquired them.
less is an exception to the rule, as it's a small, standalone program and not as critical. Its initial development start seems to predate the official announcement of the GNU Project. I don't think most people really expend much thought on something like a pager.
EDIT: Brute forcing is also a very pragmatic approach. Ken Thompson uttered his famous adage for a reason, even if it was somewhat humorous.
They do security scans, yes, but not really full-system code-quality review down to the level of every system utility (esp. not those developed primarily elsewhere). At least in the specific case of 'less', it's almost just a formality that it's even in the FreeBSD SVN tree, since the only activity is occasional re-imports of the upstream version: https://svnweb.freebsd.org/base/head/contrib/less/ Afaict, this Illumos initiative is the first attempt in years by anyone to review/clean up the internals.
There are also regular Coverity scans on the whole system (kernel and userspace) for the BSDs; the NetBSD one has been ongoing for quite some time and a lot has been fixed (a lot of the errors now seem to be in gdb...)
Another thing they could benefit from: remove aribtrary restrictions. For example, "cut" supports a custom delimiter to cut on with the -d option. But, it can only be a single character.
Why? Because that was easier for the programmer to do.
From a user's perspective, it seems pathetic.
(Yes, I know that there's sed and awk, but why force the user to switch tools so early?)
<wikipedia>
Lint first appeared (outside of Bell Labs) in the seventh version (V7) of the Unix operating system in 1979. It was derived from PCC, the Portable C Compiler, which was included with that system. Lint and PCC were developed by Stephen C. Johnson, who also authored the parser generator yacc.
I wonder what other nasty things would appear after a serious code review of the GNU and BSD core code bases.
I do agree that the code has been read probably hundreds of times and executed millions of time, but I doubt there have been many formal attempts at improvement and the overall methodoloy resembles brute forcing to me.
I could be wrong.