comment #11:

> comment #2:
> > there is a way to determine INT_MAX from within the roff language.
> [...]
> > "Within a diversion, in the absence of a diversion trap, [the .t
> > register] is the largest representable integer in basic units."
>
> By my reading of the code change in commit 5505e9864 (I've yet to compile said change to verify), neither my statement nor the quoted line of the manual is true any longer.

No, it's still true, for devices with a vertical resolution of 1.

$ ./build/test-groff -T ps
.di foo
.tm .t=\n(.t
.t=2147483647
.nr t \n(.t
.nr t +1
troff:<standard input>:4: error: integer addition wrapped
.di
.ex

The trouble is, it wasn't true even before, for devices with non-unit vertical resolutions.

$ ~/groff-stable/bin/groff -T utf8 # a.k.a. 1.23.0
.di foo
.tm .t=\n(.t
.t=2147483600
.nr t \n(.t
.nr t +1
.tm t=\nt
t=2147483601
.di
.ex

comment #5:

> 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,

I have to backpedal on my own argument here: this point, as far as I can see now, remains just as true no matter what big number .R holds.  Groff having no fixed register limit, 10,000 and INT_MAX are equally wrong values to return, but equally useful in terms of back compatibility to documents for ancient troffs.

comment #7:

> comment #6:
> > When fixing it so that \n[.t] really did return INT_MAX
> > in a diversion, things started to go wrong.
>
> So perhaps the fix is to insert the word "nearly" in the documentation before the phrase "the largest representable integer." ;-)  Kinda joking, but also, the exact value here doesn't really matter, right?

Probably not here, no.

> Absent any other mechanism for discovering INT_MAX--as roff languages have been since forever--to the roff coder there's no effective difference between "\n[.t] is the largest representable integer" and "\n[.t] is a really big number."  As long as it's always the same really big number, the hack in comment #2 lets the roff coder determine what that number is should they need to compare subsequent \n[.t] interpolations against it.

Yes, but part of what I'm worried about is the possible existence of there being other ways to trip over what appears to be deficient integer overflow handling.

> > This appears to be a kludge covering some sins in integer
> > arithmetic handling.
>
> I don't know the nature of those sins, but they could be as benign as "doing it 'right' makes these algorithms way more complicated than when using a close-enough approximation."

I'm less concerned with complexity here than with there being an access hatch from the roff language to undefined behavior in C/C++.

Also I will admit that Heirloom returning a correct INT_MAX for \n[.t] in a diversion while we don't chaps me a little.  ;-)

comment #2:

> I have to update my enthusiasm level from "I like this" to "I'm OK with this," because I just discovered there is a way to determine INT_MAX from within the roff language.  Branden already knew this, having rewritten the relevant info-manual sentence in 2020: "Within a diversion, in the absence of a diversion trap, [the .t register] is the largest representable integer in basic units."
>
> Sure enough:

> .di dummy
> .nr int_max \n[.t]
> .di
> .tm int_max is \n[int_max]

> spits out "int_max is 2147483646" on stderr.
>
> (It's intriguingly off by one:

Yes.  This appears to be a kludge covering some sins in integer arithmetic handling.  When fixing it so that \n[.t] really did return INT_MAX in a diversion, things started to go wrong.

So this is yet another one of those cases where we tug on a thread and a startling number of things unravels.

I took a couple of stabs at it but angered the formatter in surprising ways.  (For instance, "fixing" integer arithmetic breaks the bracket-building escape sequence.  I still haven't figured out how.)

> but close enough for the practical uses for it Branden lists in points 1-3 (and maybe 4, but I confess I don't grok what distinguishes 4 from 3) in his initial report.)

Case #4 is the simple question "how big are integers in this programming system?"

Case #3 is "how do I (as a *roff programmer doing arithmetic) need to structure my operations to avoid overflows, in intermediate calculations or otherwise"?

There is a miniature science to this.

https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow

comment #3:

> 1. Having to create a diversion just to discover this
> implementation limit, which is in no way restricted to
> diversion applications, feels lame.

It's definitely hackish, and certainly not obvious to even (some) semi-experienced roff users.  A simple, documented interface is certainly better; I was just pointing out (perhaps only to myself, or perhaps to a vast silent savannah audience) that it's not impossible, nor even particularly difficult, with existing groff.  As an added benefit, the hack is portable, at least to Heirloom (which, as a bonus, actually gets the number right).

Also, without knowing what the largest integer is, how does one distinguish between a diversion trap that's very far away from the current position (i.e., a very large value of \n[.t]) and no diversion traps being set (i.e., also a very large value of \n[.t])?  This could be item 5 on your use-case list -- though for it to work as such, the off-by-one would have to be redressed.

I have to update my enthusiasm level from "I like this" to "I'm OK with this," because I just discovered there is a way to determine INT_MAX from within the roff language.  Branden already knew this, having rewritten the relevant info-manual sentence in 2020: "Within a diversion, in the absence of a diversion trap, [the .t register] is the largest representable integer in basic units."

Sure enough:

.di dummy
.nr int_max \n[.t]
.di
.tm int_max is \n[int_max]

spits out "int_max is 2147483646" on stderr.

(It's intriguingly off by one:

$ groff
.nr big1 2147483646
.nr big2 2147483647
.nr big3 2147483648
troff: <standard input>:3: numeric overflow

but close enough for the practical uses for it Branden lists in points 1-3 (and maybe 4, but I confess I don't grok what distinguishes 4 from 3) in his initial report.)

I have a few uses in mind for .R.  It is presently fixed at 10,000, which is not presently a useful value for any particular purpose.  It just means "large", and I've never seen any code that tests it for its historical purpose (checking for register availability, a sort of crude memory capacity test).

1. We could advise users to employ it if they want to turn on centering or right-alignment "forever".

2. We could advise users to use it, or turn our own macro packages toward it, for expression of an "infinite" page length.

3. If done carefully, a user could avoid integer overflow errors before undertaking arithmetic with large magnitudes.

4. It would be easy to determine the width of the underlying integer type from within the roff language.  At present the language doesn't really abstract this, it simply lays down land mines that you blunder into if your arithmetic gets too ambitious.