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

[G. Branden Robinson]

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

[comment #2 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


    _______________________________________________________

Reply to this item at:

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

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