groff <= 1.19.3, ms macros -- confusing warning for 1 < pl < 13
While following up on this: http://lists.gnu.org/archive/html/bug-groff/2007-07/msg0.html I observed this unexpected behaviour:-- $ nroff -ms .pl 10 .LP :2: warning: macro `cov*first-page-init' not defined Some further checking confirms this behaviour with `.pl N', for values of N such that 1 < N < 13. The warning message isn't useful for the average user. Indeed, it may be confusing, for the macro in question is defined in s.tmac. The warning arises because the macro is invoked by a `.wh 0' trap on the first page; it immediately deletes itself, but does not remove the trap. It then overflows the short page length, springing the trap again on the second page. Ok to apply the following patch, which resolves this? 2007-??-?? Keith Marshall <[EMAIL PROTECTED]> * tmac/s.tmac (cov*first-page-init): Remove invoking trap, to avoid possible recursion. Index: tmac/s.tmac === RCS file: /cvsroot/groff/groff/tmac/s.tmac,v retrieving revision 1.33 diff -u -r1.33 s.tmac --- tmac/s.tmac 2 Jul 2007 14:49:35 - 1.33 +++ tmac/s.tmac 14 Jul 2007 19:05:48 - @@ -134,6 +134,10 @@ .als AI cov*err-not-before-tl .als AB cov*err-not-before-tl .de cov*first-page-init +.\" Invoked by `.wh 0' trap on first page. +.\" We should not come here again, but at short page length, +.\" recursion may occur; remove trap and macro to avoid it. +.ch cov*first-page-init .rm cov*first-page-init .if !'\\n[.ev]'0' \{\ . @error must be in top-level environment, not `\\n[.ev]', ___ bug-groff mailing list bug-groff@gnu.org http://lists.gnu.org/mailman/listinfo/bug-groff
Re: groff <= 1.19.3, ms macros -- confusing warning for 1 < pl < 13
> I observed this unexpected behaviour:-- [...] > > Ok to apply the following patch, which resolves this? Please do. Werner ___ bug-groff mailing list bug-groff@gnu.org http://lists.gnu.org/mailman/listinfo/bug-groff
Re: groff <= 1.19.3, ms macros -- confusing warning for 1 < pl < 13
On Sunday 15 July 2007 06:06, Werner LEMBERG wrote: > > I observed this unexpected behaviour:-- [...] > > > > Ok to apply the following patch, which resolves this? > > Please do. Done. FWIW, and for completeness, I did also check with:-- $ nroff -ms .pl 0 .LP :2: warning: number register `0:ds-type' not defined :2: warning: number register `0:LL' not defined :2: warning: number register `0:ri' not defined :2: warning: number register `0:LT' not defined :2: warning: number register `0:li' not defined :2: warning: macro `FAM' not defined :2: warning: number register `0:PS' not defined :2: warning: number register `0:VS' not defined :2: warning: number register `0:PD' not defined :2: warning: number register `0:PI' not defined and with:-- $ nroff -ms .pl 1 .LP : : :2: fatal error: input stack limit exceeded (probable infinite loop) The `.pl 0' case is clearly some part of the initialisation code being skipped, at zero page length, while the `.pl 1' case is, presumably, recursive springing of the top of page trap. I guess it should be possible to protect against these two cases, but, given the limited usefulness of these short page lengths, it may not be worth the effort. Regards, Keith. ___ bug-groff mailing list bug-groff@gnu.org http://lists.gnu.org/mailman/listinfo/bug-groff