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

[G. Branden Robinson]

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


    _______________________________________________________

Reply to this item at:

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

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