[bug #68571] [troff] `shift` request should not perform operation if argument invalid

--8323329-1714636915-1785208852=:2871749
Content-Type: TEXT/plain; CHARSET=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: inline

URL:=0A  <https://savannah.gnu.org/bugs/?68571>=0A=0A                 Summa=
ry: [troff] `shift` request should not perform operation=0Aif argument inva=
lid=0A                   Group: GNU roff=0A               Submitter: gbrand=
en=0A               Submitted: Tue 28 Jul 2026 03:20:48 AM UTC=0A          =
      Category: Core=0A                Severity: 3 - Normal=0A             =
 Item Group: Feature change=0A                  Status: Confirmed=0A       =
          Privacy: Public=0A             Assigned to: None=0A             O=
pen/Closed: Open=0A         Discussion Lock: Unlocked=0A         Planned Re=
lease: None=0A=0A=0A    ___________________________________________________=
____=0A=0AFollow-up Comments:=0A=0A=0A-------------------------------------=
------------------=0ADate: Tue 28 Jul 2026 03:20:48 AM UTC By: G. Branden R=
obinson <gbranden>=0A=0A$ cat ATTIC/shift.groff=0A.de xx=0A.  shift X=0A.  =
tm \\$1=0A..=0A.xx foo bar=0A$ groff -a ATTIC/shift.groff=0Atroff:ATTIC/shi=
ft.groff:5: error: numeric expression containing character 'X'=0Ais invalid=
=0Abar=0A=0A=0AThis straddles bug fix/feature change territory.=0A=0ASee NE=
WS items pending _groff_ 1.25 release.=0A=0A=0A*  The `dt` request, when gi=
ven invalid arguments, now does nothing=0A   instead of removing any existi=
ng diversion trap.  This change is=0A   inconsistent with AT&T troff but mo=
re consistent with general *roff=0A   syntax; as a rule, requests given inv=
alid arguments (and that don't=0A   process a list of similar objects, as `=
rm` and `rr` do) perform no=0A   operation.  (However, see "Other differenc=
es" in groff_diff(7) or=0A   groff's Texinfo manual regarding `rm` and `rr`=
 request behavior that=0A   is discrepant among various troffs.)=0A=0A*  Th=
e `dt` and `wh` requests now enforce their requirement of space=0A   betwee=
n their arguments.  While consistent with GNU troff input=0A   syntax, said=
 enforcement is not consistent with AT&T troff.  We did=0A   not add suppor=
t in groff's AT&T troff compatibility mode because=0A   we're aware of no l=
egacy documents that require it.  Example:=0A   `.wh9i+.5+\n(xxuPT` is, whi=
le validly planting a trap for the `PT`=0A   macro in AT&T troff, an input =
considerably more cryptic than any=0A   specimens known to us.=0A=0A=0AIn t=
his case, there is no compatibility with AT&T _troff_ to break.=0A=0AHandle=
 this for _groff_ 1.26.=0A=0A=0A=0A=0A=0A=0A=0A    ________________________=
_______________________________=0A=0AReply to this item at:=0A=0A  <https:/=
/savannah.gnu.org/bugs/?68571>=0A=0A_______________________________________=
________=0AMessage sent via Savannah=0Ahttps://savannah.gnu.org/=0A
--8323329-1714636915-1785208852=:2871749
Content-Type: APPLICATION/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCamggFAAKCRCqLAuaBUf3
TnzZAQD25E9FnitTE0NvwERwXTDrgSso5l7VgkfX5RFEg+5e9gD9H0r1RAYtXMzI
L/APTiKKPHf9jZ60nmT+DxjIvT/APAU=
=wgYc
-----END PGP SIGNATURE-----

--8323329-1714636915-1785208852=:2871749--