Re: roff.c question

[Kristaps Dzonsons <kristaps@bsd.lv>]

Ingo,

>>> 2) We should implement some kind of stack limit
>>>     and just bail out.
>>>
>>> OK to commit the following patch, too?
>
>> Ingo, this is fine by me---conditional upon (1) making the variable
>> be part of struct roff
>
> Hmmm, that doesn't work, struct roff is defined locally in roff.c,
> so in main.c it has incomplete type.
>
>> and not static,
>
> But that part does work, i have just made it a member of
> struct curparse.

Ehhh, you know what I mean. :-)  No function-scoped statics in the 
libraries!

>> and (2) stating the existence of a limit in roff.7.
>
> Done, in all brevity.
>
>> I realise this is putting a lot of technical
>> detail in roff.7 (as per last patch response, too)
>
> Well, the roff language is full of obscure technicalities,
> so we can't help that.  Hopefully, manual authors will rarely
> need information from roff(7) and get away with mdoc(7).
>
>> but I'm really, really sick of groff's crappy, undocumented
>> behaviour and would rather too much than too little.
>>
>> Can you pop an entry into the TODO to the extent that more rigorous
>> checking of looping constructs should be enacted?
>
> Done.

Great---check it in (I only see the TODO parts checked in in the commit 
mailings)!

Thanks and thanks,

Kristaps

--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv