[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 20:31:46 -0400 (EDT)

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

[comment #7 comment #7:]
> [comment #6 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

> > 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.  ;-)


Reply to this item at:


Message sent via Savannah

reply via email to

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