URL: <https://savannah.gnu.org/bugs/?67571>
Summary: .class works or not depending on where in the input
it's called
Group: GNU roff
Submitter: barx
Submitted: Fri 03 Oct 2025 01:04:53 AM CDT
Category: Core
Severity: 3 - Normal
Item Group: Incorrect behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Fri 03 Oct 2025 01:04:53 AM CDT By: Dave <barx>
This one smells a lot like bug #67570. But I see #67570 only on a new build,
whereas I can demonstrate this bug in older groffs.
The input file below has the same .class line in two different places; one or
the other (or neither) can be called by setting a register (or not) on the
command line. Both .class lines appear before the .cflags line that uses the
class; only one of them seems to work.
$ cat colon.roff
.if \n[early] .class [EOS] :
I:
fold.
.br
.if \n[late] .class [EOS] :
.cflags 1 \C'[EOS]'
I:
fold.
$ groff -Z colon.roff | grep ^wh
wh2500
wh2500
$ groff -r early=1 -Z colon.roff | grep ^wh
wh2500
wh2500
$ groff -r late=1 -Z colon.roff | grep ^wh
wh2500
wh5000
I get the above results whether I use groff 1.22.4 or 1.23.0. (The other
historical groff I have at hand, 1.19.2, had not yet implemented the .class
request.)
In bleeding-edge groff, #67570 seems to rear its ugly head with late=1:
$ groff-latest -r late=1 -Z colon.roff | grep ^wh
wh2500
wh2500
But early=1 output being different from late=1 is a longstanding bug. It may
have the same root cause as #67570, but since I don't have enough info to say
that for sure, I'm filing it separately for now.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67571>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
