Re: exit_status persistence (now: roff.c question).

[Kristaps Dzonsons <kristaps@bsd.lv>]

[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]

>>> Ingo, I flushed out some peculiar behaviour in the new main.c.
>>>
>>> If a FATAL parse error occurs (e.g., rxdebug.1) when multiple files
>>> are passed on the command-line, subsequent files are parsed but not
>>> outputted. This occurs due to main.c:484. I don't want to monkey
>>> with exit_status---can you verify that exit_status may somehow be
>>> saved or reset between parses so that passing multiple files doesn't
>>> cause truncated output?
>>
>> Looking at the code, i'd say you are right, this looks like a blatant
>> design error and needs to be fixed.
>> I'll probably split exit_status into two variables:
>> First, file_status will be initialized to MANDOCERR_OK for each
>> file, and that's the one mmsg will write to.
>> Then, at the end of each file, the contents must be moved to
>> exit_status, in case it's more severe than what is already there.
>>
>> I'll cook up a patch after completing the bsd.lv -> OpenBSD merges.
>> Merge, then write code is usually better than the other way round. :)
>
> Another question---I'm about to check in roff.c as fully in sync after
> running some more tests---I notice that `de1' has been removed from the
> switch statement at roff.c:549. I understand this is because `de1' is
> renamed at roff.c:636. If this is the case, can you document this
> process a bit more?
>
> There's also an infinite loop somewhere in these new roff.c changes
> that's causing the NetBSD manuals to blow up...

Replying again to myself...

The groff_char.man page causes the blow-up (enclosed).

[-- Attachment #2: groff_char.man --]
[-- Type: application/x-troff-man, Size: 35603 bytes --]