bugGNU roff - Bugs: bug #65702, tmac/doc.tmac: compatibility mode...

 
 

bug #65702: tmac/doc.tmac: compatibility mode not restored at end

Submitter:  Bjarni Ingi Gislason <bjarniig>
Submitted:  Mon 06 May 2024 08:36:27 PM UTC
   
 
Category:  Macro package mdoc Severity:  2 - Minor
Item Group:  Lint Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 07 May 2024 11:06:39 AM UTC, comment #3: 

Ah, it's a theoretical concern.

1.  groff is not in general installed with compatibility mode on by default, not on any system.

2.  What does happen is that, if "compatibility wrappers" are generated for certain macro packages, those wrappers get a "cp 1" request injected into them.

https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/tmac.am?h=1.23.0#n301

See in particular line 311.  The logic is fairly old.

https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/Makefile.sub?h=1.22.3.real#n137

These wrappers came in via a contribution from Peter Bray in 2015.

https://git.savannah.gnu.org/cgit/groff.git/tree/ChangeLog.122?h=1.23.0#n2103

...to address bug #44784.

3.  The list of macro packages for which compatibility wrappers may be generated is dynamically generated (by looking in the system troff's "tmac" or "macros" directory for files without an FSF copyright notice).  In practice, this tends to include "an", "m", and "s".

4.  "doc" (mdoc) is not in that list.

5.  Solaris 10 evidently never bothered picking up the package from 4.3BSD-Reno or later.  Makes sense, as by the time of that BSD release, AT&T had an investment stake in Sun and was steering it to a System V base.

So this doesn't really matter much.  Demoting to "minor", "lint".

If it ever causes a problem on an actual system, it can be re-promoted.

G. Branden Robinson <gbranden>
Group administrator
Tue 07 May 2024 10:50:28 AM UTC, comment #2: 

Revising summary; Bjarni identified the wrong register.

And the value of the registers `.C` and `.cp` aren't what is squarely on point.

The question is, is the enablement status of AT&T compatibility mode different when groff finishes reading a macro file than when it started?

That is what can cause input to be processed unpredictably.  The registers are merely indicia.

Here's background from 4 years ago.


commit 6a37bb5f00d881e50856dc5906f03e64dcacd1ec
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Apr 17 00:05:15 2020 +1000

    Implement new read-only .cp register.

    The register \n[.cp] is specialized and may require a statement of
    rationale.  When writing macro packages or documents that use groff
    features and which may be mixed with other packages or documents that do
    not—common scenarios include serial processing of man pages or use of
    the .so or .mso requests—you may desire correct operation regardless of
    compatibility mode in the surrounding context.  It may occur to you to
    save the existing value of \n(.C into a register, say, _C, at the
    beginning of your file, turn compatibility mode off with “.cp 0”, then
    restore it from that register at the end with “.cp \n(_C”.  At the same
    time, a modular design of a document or macro package may lead you to
    multiple layers of inclusion.  You cannot use the same register name
    everywhere or you risk “clobbering” the value from a preceding or
    enclosing context.  The two‐character register namespace of AT&T troff
    is confining and mnemonically challenging; you may wish to use groff's
    more capacious namespace.  However, attempting “.nr _my_saved_C \n(.C”
    will not work in compatibility mode; the register name is too long.
    “This is exactly what .do is for,” you think, “.do nr _my_saved_C
    \n(.C”.  The foregoing will always save zero to your register, because
    .do turns compatibility mode off while it interprets its argument list.
    What you need is:
            .do nr _my_saved_C \n[.cp]
            .cp 0
    at the beginning of your file, followed by
            .cp _my_saved_C
    at the end.  As in the C language, we all have to share one big
    namespace, so choose a register name that is unlikely to collide with
    other uses.

    * src/roff/troff/input.cpp (do_request, init_input_requests): Implement
      it.

    * doc/groff.texi:
    * man/groff.7.man:
    * man/groff_diff.7.man: Document it.

    * src/roff/groff/groff.am:
    * src/roff/groff/tests/dot-cp_register_works.sh: Test it.

    Enables a fix for <https://savannah.gnu.org/bugs/index.php?58162>.

    Thanks to John Gardner and Ingo Schwarze for the discussion.

commit f25eba40278f5a6b8b370193755c2341722bc641
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Apr 17 20:41:22 2020 +1000

    NEWS: Add item for \n[.cp].

    Also use more correct nomenclature for other *roffs.

    ChangeLog: Add summary of what \n[.cp] actually _is_.

commit 1474eebe1f83c439dd6d422a311c1c39417fac40
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sun Apr 19 15:24:24 2020 +1000

    **/*.{man,tmac}: Save compatibility mode robustly.

    Use new \n[.cp] register to save compatibilty mode.

    Use register names based on the filename (at the source maintenance
    level) to avoid clobbering other files' saved compatibility modes.

    tmac/html.tmac: Eliminate reference to saved-compatibility register by
    moving its test inside the block where compatibility mode is off.  This
    is the only part of this changeset that was not automated.


I might have overlooked mdoc, since it had different fingerprints all over it.

Or it may not have been a problem.

Or someone would have complained about this, except no user of groff on Solaris 10 has formatted mdoc pages since 2001 or earlier.

I think I'll see if I can reproduce an actual problem here.  If I can't, this ticket is either lint or invalid.

I should probably hasten to add that not every macro file needs to be bracketed with compatibility mode saving and restoration logic.  The reasons are documented and/or obvious, but I leave them as an exercise for the bug submitter.

G. Branden Robinson <gbranden>
Group administrator
Mon 06 May 2024 09:44:07 PM UTC, comment #1: 

This situation dates back to primordial groff.

The current .cp line was introduced in the 2001 rewrite of doc.tmac in commit 058f72af8.  That rewritten version did not save/restore the previous mode, and no one seems to have added such logic subsequently.

The pre-2001 doc.tmac file was imported (from a Berkeley version) in 1992 in groff 1.05 (commit a48ab7b6d), when it lived at macros/tmac.doc.  This version of the file also blindly did a ".cp 0" without saving or restoring the previous mode (presumably a James Clark customization of the Berkeley file).

So it seems intentional, or at least hasn't caused any reported misbehavior in over 30 years.  Do you see any properly formed mdoc document misbehaving because of the hard-coded mode?

original submission:

> previous state of compatibility (register '.cp') is not restored


The request to change the mode is ".cp".  The corresponding register is ".C".

Dave <barx>
Group Member
Mon 06 May 2024 08:36:27 PM UTC, original submission:  

Subject: tmac/doc.tmac: previous state of compatibility (register
'.cp') is not restored at end

  There is only this

.do if d Dd .nx
.
.
.cp 0
.
.
.\" Define a string for use in diagnostic messages.

Bjarni Ingi Gislason <bjarniig>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by bjarniig (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-06-05 gbranden Assigned togbranden None
    2024-05-12 barx StatusNeed Info None
    2024-05-07 gbranden Severity3 - Normal 2 - Minor
        Item GroupIncorrect behaviour Lint
    2024-05-07 gbranden Assigned toNone gbranden
        Summarytmac/doc.tmac: previous state of compatibility (register '.cp') is not restored at end tmac/doc.tmac: compatibility mode not restored at end
    2024-05-06 barx StatusNone Need Info

    Back to the top

    Powered by Savane 3.14-8eb0.
    Corresponding source code