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/