[Top][All Lists]
[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.
node.cpp.patch.bz2
Description: BZip2 compressed data
- Re: [Groff] pdfmark strikes back + general script/groff handshake,
Keith Marshall <=