Re: [RFC] input.cpp: Remove use of strncat(3)

[G. Branden Robinson]

[dropping Larry from Cc because we don't appear to have significant
common ground in this discussion]

I had this mentally queued for reply; thanks, Dave, for writing and
prompting me to finally shift on it.  :)

At 2022-12-09T15:52:11-0600, Dave Kemper wrote:
> I have no opinion about this particular change, but to address this
> general point:

I can see both Alex's and Larry's points, as I understand them, on this
issue.

On the one hand, I agree that without some concrete evidence of groff
using strncat() unsafely, it cannot be urgent to refactor away from it.
I have multiple times downgraded bug reports from Bjarni, for instance,
that raise only theoretical problems.  (Sometimes I later discover
behavior that makes one non-theoretical, and I raise its severity and go
ahead and fix it.)

On the other hand, I don't share Larry's effort estimate with respect to
tracing the history of code.  Notwithstanding any suggestions that
BitKeeper was bigger, more complex, more sophisticated, and written and
maintained by people with much bigger brains than poor old groff, I have
on _many_ occasions traced groff bug histories back to their origins,
and I include this information in the ChangeLog when I have confidence
in it.

Thanks to TUHS, I can dig back even farther than the dawn of our
repository's history (groff 1.02) and gaze upon groff 1.01.[1]

It does not take me a day, or even the better part of one, to perform
this exercise.  It's a matter of iterating "git blame", locating a
source line of interest, and "git checkout HASH^" (note the trailing
caret).  I don't think this procedure has ever taken me longer than 10
minutes for any issue--git bisects are often slower simply due to build
times--which makes me only half as speedy as one of Larry's
non-refactoring engineers, but still far ahead of the day-long
turnarounds he dreaded.

Because I value clarity, and the removal of absurdities like "internal
name" meaning two completely different things when referring to fonts, I
regard the trade-off as worthwhile.[2]

> On 12/5/22, Larry McVoy <lm@mcvoy.com> wrote:
> > I used to run a company that did source management tools and we
> > strongly discouraged these sorts of "clean ups" because they change
> > the author of that line of code.  Our system made it painless to go
> > from a line of code to the commit that added that line of code.
> > Which, if it goes back to the original commit, is super pleasant for
> > debugging.  If I have go to your commit, then realize, oh, it used
> > to be the commit before that and so on, it takes longer to figure
> > out the bug.
> ...
> > So there is real value to asking yourself "Am I actually fixing a
> > real bug?"

In languages like C and C++, it can be nearly impossible to answer this
question.

> While I'm a big proponent of the "if it ain't broke, don't fix it"
> school of thought, just in my limited trawling of groff's "git blame,"
> this already seems like a lost cause.  Especially recently, there's a
> lot of churn in the source code.

I wouldn't say a _lot_... ;-)  I did a pull of Texinfo recently, and for
a project that was once moribund, it's a hive of activity these days.

> If that's representative (which I bet it roughly is, as input.cpp is
> pretty central to groff), over 1/3 of groff's code changes do not
> affect its operation.

I have no idea whether to be proud, ashamed, or simply indifferent to
that statistic.  Because the behavior of any nontrivial program cannot
be exhaustively characterized--well, not easily, anyway, and not without
formal methods--it is hard in the abstract to even value operational
changes as positive or negative on a basis independent of their intended
purposes.

> > And it is groff, not some mission critical database.

Nearly every change I make to groff is in the direction of improved
quality of implementation as I understand it.

> > If I were in charge, I veto these sorts of commits and fix the
> > problems if/when they arise and have a cleaner history.

"These sorts" is a broad and ill-defined classification.  We know how
these work in practice; the guy in charge is an oracle.  Oracles are
unreliable; this is why modern technology and medicine are based on the
scientific method rather than getting stoned on hydrocarbon vapors in
Pythia.[3]  The usual way around this to pronounce the oracle
infallible, a method that suits chief executives just fine.  Larry has
demonstrated, for example, that his opinions of groff, insofar as its
documentation goes, are not informed ones.[4]  I see that there is
recent literature on "minimizing guesswork with unreliable oracles".[5]
I reckon bosses intuitively figured this out long ago; it's why they
cultivate techniques for making their underlings shut up.  Savvy
subordinates find ways to avoid interacting with them at all.[6]

> That knife cuts both ways: because it's not mission critical, the time
> it takes to debug problems is less important, so there needn't be any
> particular effort to minimize the amount of changes in the history.
> (If such effort even has the effect of speeding up debugging: as Alex
> points out in his reply, whatever the cost of making a useful
> refactoring commit, there is also a cost associated with NOT making
> that change, in terms of code readability or comprehensibility.  These
> can also be impediments to debugging.)

Armchair economists usually venture something about opportunity costs at
this point in a discussion.  Austrian-school types deploy the
immeasurable subjectivity of value judgments as a shield against
any falsification of their program on empirical grounds, so I will
simply that say that it's worth it to _me_ to make groff more robust,
better documented, and more helpful when it issues diagnostic messages.

On a happier note, if you want a _good_ book about opportunity costs, I
recommend John Quiggin's _Economics in Two Lessons_.  (His _Zombie
Economics_ is more fun, though.)

Regards,
Branden

[1] 
https://minnie.tuhs.org/cgi-bin/utree.pl?file=Net2/usr/src/usr.bin/groff/VERSION
[2] We'll probably ship 1.23.0 with this absurdity because it's only
    visible when you dig fairly deep into font management.  I don't
    regard my own itches as urgent just because they're mine.
[3] Though it would be fair to point out that we moderns are more addled
    by hydrocarbons than our Athenian forebears could have conceived.
[4] https://lists.gnu.org/archive/html/groff/2022-07/msg00182.html
[5] https://ieeexplore.ieee.org/document/8437509
[6] 
https://www.reddit.com/r/EnoughMuskSpam/comments/z2ofwk/i_was_an_intern_at_spacex_years_ago_back_it_when/

signature.asc
Description: PGP signature