Re: [groff] 15/39: [grog]: Drop relic code and comments.

[G. Branden Robinson]

Hi Dave,

At 2022-10-30T23:41:43-0500, Dave Kemper wrote:
> On 10/30/22, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> > Perl 5.6.1 is incredibly old (April 2001).  I cannot find any
> > evidence of any current distribution supporting it.
> 
> I'm less convinced by this -- unless a difficult roadblock stands in
> the way, I think modern groff ought to work or fail gracefully on an
> obsolete platform -- but the prior two points are convincing enough on
> their own.

I broadly sympathize with this but I find it a matter of tradeoffs.

In general, languages are changed in ways that improve them.  Take C,
for instance.  While there will always be religious fanatics,
particularly those who confuse recreational retrocomputing with software
engineering, who proclaim that ISO C90, or K&R 1978 C, or Typesetter C
was some sort of global maximum, the broad consensus of communities of
language is in the direction of development to suit current needs.
There are occasional blunders--C++ seems to have made a few--I think the
general trend holds for languages that remain in use decade over decade.

Perl is a big language that provides a big runtime, and it has
consequently absorbed its fair share of black eyes in the security
department.  I don't see a lot of value in bending over backwards to
accommodate versions of the language that the vast majority of its own
practitioners no longer embrace.

But I will reiterate the broadest point from my previous message: I'm
loath to assert that a Perl script in groff requires a particular
minimal version of Perl _if we can't articulate why that is the case_.
If some Perl revision historian with a horizon of 20+ years wants to
check over our scripts to point out just how far back we can set the
"require" clock for each one, and can itemize a bill of particulars, I'm
happy to incorporate that knowledge in the scripts themselves, which is
the best place for it.

For (the forthcoming) groff 1.23, we have the following in our
INSTALL.extra file.

  groff is predominantly written in ISO C++98, so you need a C++
  compiler capable of handling this standardized version of the
  language.  The C++ source files use a suffix of '.cpp'; your C++
  compiler must be able to handle this.  A C/C++ preprocessor that
  conforms to ISO C90 is also required.  If you don't already have a C++
  compiler, we suggest GCC 9.4 or later.  To override the 'configure'
  script's choice of C++ compiler, you can set the CXX environment
  variable to the name of its executable.

  A few components of groff are written in ISO C99.  Features later made
  optional by ISO C11 (the 'complex' primitive data type and
  variable-length arrays) are not used.

Strictly speaking, I suspect it's possible to build the C components of
groff with ISO C90--the only C99 features I can remember us using off
the top of my head are the 'bool' type and the enhanced assert().  We
have an Autoconf check for stdbool.h,[1] and I suppose gnulib could
provide it for us if necessary, and provide our own implementation of
the latter.[2]

I haven't tested my guess because I just don't find it that important.
If someone else would like to give it a shot and tell me how it goes,
I'm curious to know the result.

Taking these three languages together, we have a portability horizon
going back to 1998-2001.  I think that's pretty generous for a
contemporary project.

> Makes sense.  I thought this audit might be onerous,

The blood drained from my face for a brief moment, but then I remembered
that grog isn't a preprocessor.  It only reads the input files; it does
not rewrite them.  And I in fact use grog _all the time_; I have shell
functions that I use for browsing man pages in the build tree,[3] and
they use grog.  Amusingly enough, this goof on my part "didn't break
anything" (meaning: my common case).  They removed newlines from
"--version" output, which you noted but which nothing attempts to parse;
from diagnostic messages; and, amusingly enough, if you wrap up grog's
output in a shell command substitution, a missing newline causes no
grief.

So I got a nice little harmless jump scare just in time for Halloween.
:D

Regards,
Branden

[1] 
https://git.savannah.gnu.org/cgit/groff.git/tree/configure.ac?id=8446562250babffcb185cb1f75454c9ff950cae2#n91
[2] 
https://git.savannah.gnu.org/cgit/groff.git/tree/src/include/assert.h?id=8446562250babffcb185cb1f75454c9ff950cae2

[3]

gman ()
{
    local width=$(stty size | cut -d' ' -f2);
    width=$(( width - 1 ));
    ./build/test-$(./build/grog -Tutf8 -b -ww -P-i -rU1 \
      -rLL=${LL:-$width}n "$@")
}

mailman ()
{
    ./build/test-$(
            ./build/grog -Tutf8 -b -ww -rU1 -rLL=72n -rHY=0 -dAD=l \
                -rIN=4n -rSN=2n "$@")
}

signature.asc
Description: PGP signature