Re: Proposal: remove usr.bin/mkstr

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 9 Apr 2022 15:16:24 +0200
    From:        Roland Illig <roland.illig%gmx.de@localhost>
    Message-ID:  <bd2627e3-989d-3e92-802c-b203c9c3ce42%gmx.de@localhost>

  | I don't get how mkstr or a similar tool could help in such a situation.

Nor do I right now, but nor do I know of an immediate need.

  | 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.

Probably.

  | I doubt that each of these projects would use NetBSD's
  | mkstr to extract the few string literals that might bloat the code.

No, they probably wouldn't.  But nor will they probably care about
32 bit cpu support at all, everything new (for the general computing
market) is 64 bit.   Caring in general about 32 bit in a few more
years is likely to be just about as common as caring about 16 bit
cpus is today.

If we want to keep supporting the 32 bit systems we currently support
(or at least some of them) someone here is likely going to need to
do the work to shrink things to fit.  That is when they are needed.
Whether mkstr will ever be useful to assist with that I have no idea,
but I believe that it is not costing us anything to wait and find out.

If it is ever needed, it might perhaps require updates, but those
will then be justified by the benefits presumably obtained.  Until
then it just sits there, harming nothing.

  | 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.

Unless you have gained the ability to predict the future, you do
not know that.   Proposals to remove anything are likely to be
controversial.  If there is some obvious benefit to no longer
needing to maintain it, like kernel drivers for hardware no-one
uses any more, but which keep needing to be updated to compensate for
other kernel changes, or applications that are consuming lots of
developer time fixing bugs, and have no truly useful benefits,
then removal might be justified.  But when there is close to
zero real benefit, why bother?

  | Due to the above features, I'd say that lint is still useful.

Perhaps.   It is a matter of opinion ... but I am not suggesting
that we remove it, or anything else.   lint however is clearly
consuming developer time (yours mostly, but also everyone else
who follows src-changes@) so a case for removing that could be
made, retaining it has costs.  As best I can tell, mkstr has none.

  | In contrast, mkstr is a very naive program that destroys any
  | source code using perror or yyerror.

By all means, fix the Makefikes for all those programs that
are being destroyed by using mkstr to not use it.  You would
need to do that anyway if you remove mkstr.   Be sure to let
us know which those are.

  | This has probably gone unnoticed since nobody
  | ever tried to use mkstr in any productive way.

Using mkstr needs a properly constructed program, it never
was intended to simply be applied to any random code.  It
allows (allowed) the source that needed it to be written and
maintained in a reasonable way, while extracting string data
from the binary into a file from which the strings required
were read, used, and discarded, as needed.  Since we abandoned
16 bit cpu support, and haven't yet really reached 32 bit limits
much yet, there's been no need.

  | Therefore I don't see any reason to keep it.

And I have seen no reason to remove it.  Not even a hint of one.

Further, in the past day this (short) discussion has almost certainly
used more developer time than mkstr has consumed in the past decade.
Why?

Just stop suggesting removing things for no better reason than
that you see no point keeping them.  If the existence of something
which seems not to be all that necessary is being a roadblock
to getting other work done, then by all means, request assistance,
from which sometimes the solution might be to simply remove the
roadblock -- other times a suitable alternative might be found.
But while it is doing no harm, leave it alone.

kre