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

Follow-up Comment #11, bug #63587 (group groff): [comment #2 comment #2:] > there _is_ a way to determine INT_MAX from within the roff language. [...] > "Within a diversion, in the absence of a diversion trap, [the .t > register] is the largest representable integer in basic units." By my reading

[bug #66081] [troff] possible use of uninitialized heap memory

Update of bug #66081 (group groff): Summary: [troff] possible use of uninitialized stack memory => [troff] possible use of uninitialized heap memory ___ Reply to this item at: ___

[bug #62916] list things to deprecate

Follow-up Comment #10, bug #62916 (group groff): [comment #9 comment #9:] > [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=b9c70aa59 Commit b9c70aa59] deprecated .hpfcode. > > But users might benefit from the list including it anyway, to give it higher visibility than the warning emitted

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

Follow-up Comment #12, bug #63587 (group groff): [comment #11 comment #11:] > [comment #2 comment #2:] > > there _is_ a way to determine INT_MAX from within the roff language. > [...] > > "Within a diversion, in the absence of a diversion trap, [the .t > > register] is the largest representable in

[bug #66085] second run of "make" requires user interaction

Follow-up Comment #3, bug #66085 (group groff): But more conceptually, just by running "make," the user is agreeing to overwrite any files that "make" makes. Asking for agreement to overwrite some individual files is redundant. ___ Reply

[bug #66096] document behavior of multiple .hw calls

Update of bug #66096 (group groff): Summary: Document behavior of multiple .hw calls => document behavior of multiple .hw calls ___ Follow-up Comment #1: [comment #0 original submission:] > One of the changes [http://git.s

[bug #66085] second run of "make" requires user interaction

Follow-up Comment #4, bug #66085 (group groff): [comment #2 comment #2:] > I am not. I probably heard that at some point, but that probably wasn't a point at which I was building groff regularly. > > I see this is in INSTALL.extra: > 5. You can remove the groff executables and other generated

[bug #66096] document behavior of multiple .hw calls

Follow-up Comment #2, bug #66096 (group groff): [comment #1 comment #1:] > Like a lot of things with names inside GNU _troff_, > hyphenation exception words are stored in a dictionary. > Specifically, they resemble registers and > strings/macros/diversions in this respect. How things are stored

[bug #66096] document behavior of multiple .hw calls

Follow-up Comment #3, bug #66096 (group groff): I guess I managed to obscure my own point about dictionaries. I certainly to don't want to document that this is how hyphenation exception words are stored. My point is that, from the user's perspective, unless we give them a reason to think otherw

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

Follow-up Comment #13, bug #63587 (group groff): [comment #12 comment #12:] > No, it's still true, _for devices with a vertical resolution of 1_. Fair point. In fact, it's truer now than before, losing the off-by-oneness noted in comment #2. > it wasn't true even before, for devices with non-un

[bug #66001] [troff] implement saturating arithmetic

Follow-up Comment #1, bug #66001 (group groff): I think I've got it licked. All tests passing. commit bee5cf5dc98600efe48b96014572be9c056419c3 Author: G. Branden Robinson Date: Fri Aug 16 14:53:13 2024 -0500 [troff]: Fix Savannah #66001 (saturating arith). * src/roff/troff/hvun

[bug #66096] document behavior of multiple .hw calls

Follow-up Comment #4, bug #66096 (group groff): [comment #3 comment #3:] > from the user's perspective, unless we give them a reason to > think otherwise, they are free to assume that hyphenation words > are stored in the same way that registers and strings are. A user thinking along these lines

[bug #66085] second run of "make" requires user interaction

Follow-up Comment #5, bug #66085 (group groff): [comment #4 comment #4:] > The use of a file named "INSTALL" in a source distribution is > a familiar and long-standing convention. Fair point. > Moreover, the "README" file explicitly steers people to > "INSTALL.extra" and "INSTALL.REPO", Yes, bu