Re: Proposal: remove usr.bin/mkstr

[Roland Illig <roland.illig%gmx.de@localhost>]

Am 09.04.2022 um 12:20 schrieb Robert Elz:
>      Date:        Sat, 9 Apr 2022 10:10:42 +0200
>      From:        Anders Magnusson <ragge%tethuvudet.se@localhost>
>      Message-ID:  <1c33051c-45fe-931b-0159-03136c07ed24%tethuvudet.se@localhost>
>
>    | 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.

Roland