Re: Problem using llx/urx in PS_LinkDest

[KHMan]

Jeff Kingston wrote:
> You seem to be saying that there are no bugs in the canonical
> distribution, but that there is a bug in the version with your
> patch, and that the bug is a failure to initialize save_mark(x)
> in objects of type LINK_DEST.

No, my patch appears to work. The patch changes only z49, so I
doubt if it caused any changes elsewhere, but I'll later
double-check with the canonical sources.

Since the bounding box values passed to PS_LinkDest() are from
elsewhere and are never used by the canonical distribution, I
believe the bug has not been noticed before.

> However, around line 686 of z23.c I can see this:
> 
>     case LINK_SOURCE:
>     case LINK_DEST:
>     case LINK_DEST_NULL:
>     case LINK_URL:
>     
>       CountChild(y, LastDown(x), count);
>       if( dim == COLM )
>       save_mark(x) = xmk;
>       else
>       {
>       ...
>       }
>       ...
>       break;
> 
> Since the Lout memory allocator does not zero memory, save_mark(x)
> will be uninitialized up to this point, and it is not a memory
> allocator bug for it to contain an old pointer value before the
> third line of the case above is executed.  The issue is, why has
> 
>       save_mark(x) = xmk
> 
> not been executed by the time your code is reached?  This code
> should be executed twice, first with dim == COLM to work out
> horizontal placement (which then gets saved in save_mark(x)
> in these kinds of objects), then again with dim == ROWM to
> work out vertical placement and do the actual printing.

I know too little of those internals to say anything intelligent.
I inferred the memory allocation problem because a pointer value
was assigned via pinpoint(z) in z12, then the same value appears
in a LINK_DEST_* object. So at first glance, yeah, somehow that
part got bypassed.

> [snip]

Okay, I will do the following:

(a) confirm that PS_LinkDest() has bad bounding boxes in the
canonical sources (via diff of expert.ps using unchanged sources
versus one with save_mark(x) zeroed at object creation -- in
theory, there should be no difference.)

(b) try to confirm via tracing of all save_mark() instances that
the anomalous LINK_DEST_* object never passed through the (dim ==
COLM) path in the above.

Will report back later.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia