groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] pdfmark strikes back + general script/groff handshake


From: Keith Marshall
Subject: Re: [Groff] pdfmark strikes back + general script/groff handshake
Date: Tue, 4 May 2004 20:05:25 +0100

On Monday 15 December 2003 4:43 am, Carlos J. G. Duarte wrote:
> ... the solution proposed by Werner LEMBERG to make HREF pdfmarks work
> correctly. WL proposed to have a macro like this:
>
>    .nr pshref-count 0
>    .
>    .de PSHREF
>    .  tmc pshref: \\n[pshref-count]-start: \"
>    .  nop \&\O1\m[white]|\m[]\h'-\w'|'u'\O2\c
>    .  tmc pshref: \\n[pshref-count]-end: \"
>    .  ie !'\\$3'' \
>    .    nop \\$3\O1\m[white]|\m[]\h'-\w'|'u'\O2\c
>    .  el \
>    .    nop \\$1\O1\m[white]|\m[]\h'-\w'|'u'\O2\c
>    .  nr pshref-count +1
>    ..
>
> And then parsing its output to generate the inline PS code. There is
> actually a minor problem with the above stuff: it was pretended to
> output lines like this
> pshref: 1-start: grohtml-info:page 1 ...
> pshref: 1-end: grohtml-info...
> but the output does not come in order, i.e. on the example I was trying
> the "pshref: 1-start" kind of lines appear first all together and then
> the "grohtml-info" lines.

Indeed. I see the same effect. I guess the explanation is that the .tmc 
requests write immediately to stderr, when they are processed on *input*, 
whereas the \O2 output is deferred until *after* the output line containing 
the escape is fully adjusted by gtroff.

Actually, this is not the only problem with this. On my Win2K box, with groff 
compiled using the MinGW compiler, the \O2 escape causes gtroff to crash, 
with the Win32 equivalent of SIGSEGV, while attempting to read data from 
memory at absolute address 0x00000000, which leads me to suspect a memory 
access via an uninitialised pointer.  Sure enough, in node.cpp I see

        sprintf(name, last_image_filename, last_image_id);

where `last_image_filename' is a static variable, with file scope, and 
initialised to (char *) 0.

This problem does not seem to show up on GNU/Linux boxes -- it should, since 
the dereference of the NULL pointer should result in SIGSEGV! Perhaps, the 
glibc implementation of sprintf() provides protection against the use of a 
NULL pointer for the format string -- the manpage does not say -- thus 
concealing this error.  In any case, the Microsoft implementation has no such 
protection, so gtroff crashes.

The attached patch corrects this defect.

Best regards,
Keith.


Attachment: node.cpp.patch.bz2
Description: BZip2 compressed data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]