bugGNU roff - Bugs: bug #44714, compatibility mode: .do request...

 
 

bug #44714: compatibility mode: .do request and macro expansion via \* collide

Submitter:  Werner LEMBERG <wl>
Submitted:  Fri 03 Apr 2015 02:03:22 PM UTC
   
 
Category:  Core Severity:  2 - Minor
Item Group:  Incorrect behaviour Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 06 May 2024 01:13:42 AM UTC, comment #4: 

comment #3:

> Probably until this is fixed (which may be a while if it proves as
> intractable as Werner predicts), the andoc.tmac comment should cite
> this ticket rather than vaguely referring to "a bug in GNU troff."


This is now covered by bug #62826.

Dave <barx>
Group Member
Wed 01 May 2024 06:04:12 AM UTC, comment #3: 

comment #1:

> I don't understand why '.do tm' is going to the next input line
> to collect arguments.  'tm' is not documented in CSTR #54 as
> behaving this way.


It's not the behavior of .tm that's at issue, but of .do.

This is the bug that's referred to in this comment in tmac/andoc.tmac: "Due to a bug in GNU troff it necessary to have a no-op line between `.do' and `\*'."

This comment was added in commit 42c866a3f (which was part of the fix for bug #44708) and refers to these changes in the commit:

-.  als TH reload-man
-\\*[Dd]\\
+.  do als TH reload-man
+.
+\\*(Dd\\


-.  als Dd reload-doc
-\\*[TH]\\
+.  do als Dd reload-doc
+.
+\\*(TH\\

Indeed, removing these two empty control lines wreaks havoc, showing that a .tm isn't necessary to trigger the bug.

Probably until this is fixed (which may be a while if it proves as intractable as Werner predicts), the andoc.tmac comment should cite this ticket rather than vaguely referring to "a bug in GNU troff."

comment #2:

>   Why does '.tm' need a '.do'?


It doesn't; that's just a minimal test case to illustrate the bug.  The situation in andoc.tmac is a real-world case but not a minimal one.

Dave <barx>
Group Member
Thu 17 Feb 2022 01:50:53 AM UTC, comment #2: 

  Why does '.tm' need a '.do'?

Bjarni Ingi Gislason <bjarniig>
Thu 02 Sep 2021 03:18:38 PM UTC, comment #1: 


original submission:

> Consider the following snippet.
>


> .de1 aa
> .  tm compatibility mode = '\\n(.C'
> ..
> .
> .cp 1
> .
> .do tm
> \*(aa\


>
> The expected output is
>


> compatibility mode = '0'


>
> since macro `.aa` is defined with `.de1`.  However, due to a bug in troff you get
>


> compatibility mode = '1'


>
> instead.


I don't understand why '.do tm' is going to the next input line to collect arguments.  'tm' is not documented in CSTR #54 as behaving this way.

G. Branden Robinson <gbranden>
Group administrator
Fri 03 Apr 2015 02:03:22 PM UTC, original submission:  

Consider the following snippet.


.de1 aa
.  tm compatibility mode = '\\n(.C'
..
.
.cp 1
.
.do tm
\*(aa\


The expected output is


compatibility mode = '0'


since macro `.aa` is defined with `.de1`.  However, due to a bug in troff you get


compatibility mode = '1'


instead.

Reason of the problem is a clash between the `.do` request and the immediately following macro expansion via `\*`.

  1. In `src/roff/troff/input.cpp`, function `do_request` resets `compatible_flag` after calling `interpolate_macro` (which handles the argument of `.do`).
  2. `interpolate_macro` calls `token::next` to get the next input token, and this function expands `\*(aa` and processes tokens until it gets a 'real' one. 
  3. Since `aa` is defined with the `de1` request, it starts internally with a `PUSH_GROFF_MODE` pseudo-character that makes troff save the compatibility flag and switch off compatibility mode.  Unfortunately, this happens too early, and `do_request` overrides this.


An easy work-around is to insert a no-op line.


.do tm
.
\*(aa\


Alas, fixing this bug is not trivial, as far as I can see; it's probably necessary to redesign the compatibility mode handling.

Werner LEMBERG <wl>
Group administrator

 

(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 barx (Posted a comment)
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by bgarrigues (Updated the item)
  • -email is unavailable- added by wl (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-11-26 bgarrigues CategoryNone Core
        Severity3 - Normal 2 - Minor
        Item GroupNone Incorrect behaviour

    Back to the top

    Powered by Savane 3.13-ee12.
    Corresponding source code