Follow-up Comment #7, bug #63587 (project groff): [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? 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. > 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." > There is a miniature science to this. Thanks for that link! _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?63587> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/