URL:
  <https://savannah.gnu.org/bugs/?66686>

                 Summary: \w rejecting delimiter roffs have accepted for
decades
                   Group: GNU roff
               Submitter: barx
               Submitted: Mon 20 Jan 2025 12:09:37 PM CST
                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: Mon 20 Jan 2025 12:09:37 PM CST By: Dave <barx>
Modifying an example from the info manual to change the delimiters for \w's
argument to a + sign:

$ echo "The length of the string 'abc' is \w+abc+u." | groff -Tascii | cat -s
The length of the string 'abc' is 72u.

This has worked for decades in groff, and works in Heirloom troff.  It has no
syntactical ambiguity, because \w does not take a numeric expression.

In a bleeding-edge groff, it no longer works.

$ echo "The length of the string 'abc' is \w+abc+u." | groff-latest -Tascii |
cat -s
troff:<standard input>:1: error: character '+' is not allowed as a delimiter
The length of the string 'abc' is abc+u.

And the manner in which it fails--transforming something that used to be a
numeric expression into something that (probably) no longer is--sends things
further off the rails when calculations are attempted with this value.

This change dates from the last 5 months.  In that time frame:

* Bug #66481 fixed a similar back-compatibility-breaking problem with the \w
escape and a | delimiter.  But this couldn't have introduced the current
problem as a side effect: all it does is revert the fix for bug #66009 fix,
and the + delimiter worked fine in the pre-66009 days.
* Bug #63142 disallowed newlines as delimiters, which was an un(der)used GNU
aberration from the start.  But its commit message says "As a bonus, check
starting delimters [sic] for these escape sequences (`\[obAZwX]`) for validity
in general."  So I suspect this bug may have been introduced as part of that
bonus.







    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66686>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to