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/
