[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: G. Branden Robinson
Subject: [bug #63587] [troff] set .R register to maximum representable integer
Date: Fri, 14 Apr 2023 15:17:09 -0400 (EDT)

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

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

There is a miniature science to this.



Reply to this item at:


Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]