[bug #63587] [troff] set .R register to maximum representable integer

[Dave]

Follow-up Comment #5, bug #63587 (project groff):

Further musings:

It slightly weakens inter-roff interoperability to have \n[.R] mean different
things in different roffs.  On those grounds, perhaps there should be a new
register to return INT_MAX, and \n[.R] should be left to its original job.

And it does appear groff in fact has a register limit.  At first blush, it
looks to be far above the 10,000 reported by \n[.R]:

$ for num in `seq 1000000`; do echo .nr a$num 12; done | groff
troff:<standard input>:597608: fatal error: too many symbols

But upon further investigation, "how many registers does groff let you
define?" does not have as straightforward an answer as one might hope:
registers and strings, while not sharing a namespace, do seem to share the
same internal "symbol" pool that is being depleted above:

$ for num in `seq 1000000`; do echo .nr a$num 12; echo .ds b$num twelve; done
| groff
troff:<standard input>:597608: fatal error: too many symbols

The failure here happens on the same input line, but only half as many
registers have been defined by that point in this modified example.

This suggests it should even be possible to contrive a situation where the
number of user-defined registers available is ZERO.  And, indeed:

$ ( for num in `seq 597607`; do echo .ds b$num twelve; done; echo .tm so far
so good; echo .nr my-only-register 12) | groff
so far so good
troff:<standard input>:597609: fatal error: too many symbols

But "contrive" is the operative word there: given the point at which this
limit is being hit, I can conceive of no real-world case where one would run
out of symbols.  Similarly, I can think of no situation where a user might
need 10,001 registers, so, despite this number having no clear connection to
any internal groff limit, it's probably a reasonable limit to _claim_ to the
user who asks.  It will enable the processing of any ancient roff documents
that do test this register, and--as you note back at the start--anyone writing
documents in the groff era is unlikely to be looking at \n[.R]'s value at all.


    _______________________________________________________

Reply to this item at:

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

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