tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal: remove usr.bin/mkstr

Am 09.04.2022 um 12:20 schrieb Robert Elz:
     Date:        Sat, 9 Apr 2022 10:10:42 +0200
     From:        Anders Magnusson <>
     Message-ID:  <>

   | Besides that, mkstr is quite useless on a 32-bit architecture so
   | I would say remove it.

It is no longer really required for anything, or not right now,
but we really are not very far away from exceeding 32 bit limits
for some applications, if that has not already happened.

I don't get how mkstr or a similar tool could help in such a situation.
An application that exceeds 32 bit limits is probably composed of many
independent modules, each having its own coding style and a different
upstream author. I doubt that each of these projects would use NetBSD's
mkstr to extract the few string literals that might bloat the code.

If we plan on retaining support for 32 bit systems, we might need
all the help we can get sometime not very far into the future, and
this tool just might be sometimes helpful.

mkstr is written in a rather naive way. Its most complex part is the
lexer for C-style strings, and that code is also available in
usr.bin/indent and usr.bin/lint.

But even if not, I'd prefer to keep it.   It isn't as if it is
costing anything that matters - just leave it alone, resist the
temptation to attempt to improve it or turn it into modern code,
and mostly ignore it.   Keeping it shows that we are not ashamed
of our heritage, we came from BSD and still retain some of its
most ancient relics.

I chose mkstr because I thought it would be uncontroversial, to see
whether it is possible at all to remove a tool that was useful 30 years
ago for the last time.

I also kind of like having a man page with a Dd line from 1993,
and not just because it wasn't updated when it should have been.

true(1) is even from 1991, which makes mkstr(1) redundant to achieve
this goal.

That's just like lint - once used all the time, code was not accepted
if not lint free, now essentially useless as tge compilers have most
of its functionality built in.   If being old and no longer very useful
is the test, then lint should go too.  Perhaps so should I.

Do you know of any C compiler that can treat bool as a separate data
type from int, to catch accidental assignments to 'flag = 2' and to help
write the code in a way that is easier to read for humans?

Do you know of any C compiler that complains in a helpful way when
someone calls isspace(char)?

Do you know of any C compiler that checks that the getopt options string
matches the switch statement?

Do you know of any C compiler that catches the implicit unconst cast in
strstr("literal", "lit")[0] = 'X'?

Due to the above features, I'd say that lint is still useful. In
contrast, mkstr is a very naive program that destroys any source code
using perror or yyerror. This has probably gone unnoticed since nobody
ever tried to use mkstr in any productive way. Therefore I don't see any
reason to keep it.


Home | Main Index | Thread Index | Old Index