lout-users
[Top][All Lists]
Advanced

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

Re: Problem using llx/urx in PS_LinkDest


From: KHMan
Subject: Re: Problem using llx/urx in PS_LinkDest
Date: Thu, 08 May 2008 18:59:58 +0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4

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.

The first of the items I promised to do:

Attached is a unified diff of the expert's guide with debug stderr
stuff for two versions of Lout, where the two versions are:
(a) canonical sources, debugging on, installed to user's subdir
(b) as (a), except in object creation in z07.c, the following was
added near line 319:

      ...
      New(res, type(x));
      if (type(x) == LINK_DEST || type(x) == LINK_DEST_NULL) {
          save_mark(res) = 0;
      }
      ...

The PS output and the diff were generated using the above two Lout
executables on Ubuntu 6.10.

One would expect only the timestamp to change. However, we can see
there are many PS_LinkDest() glitches, and that's the only type of
glitch. On lines 33-34 of the attached diff, we have:

  po: PS_LinkDest("yunit", 145278000, 10319, 145278000, 10319)
  po: PS_LinkDest("yunit", 0, 10319, 0, 10319)

The first line is the canonical sources with debugging on, the
second line is with save_mark(x) zeroed. Since "yunit" is a
LINK_DEST_NULL, one would expect a zero value for x coordinates to
be correct (flush left?). Another example: On line 24, "font" has
a non-zero x coordinate value, when a value of 0 is also expected.

These glitches also change depending on changes to the sources,
e.g. if debugging is turned on or off. So, they are affected by
memory allocation patterns, and so it looks like save_mark(x) is
often not initialized properly.

The others are glitches too, but apparently based on old values of
save_mark(x), so upon visual inspection those looked like they
were well in range. They are exposed as obvious errors only by the
diff. But for "yunit" in the above, it sure looks like a pointer
from an old object. So for the canonical sources, apparently in
some cases, the object never reaches the expected COLM conditional
path and save_mark(x) is not initialized properly.

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

--- expert1.ps  2008-05-08 18:00:02.984375000 +0800
+++ expert2.ps  2008-05-08 18:03:35.312500000 +0800
@@ -1,6 +1,6 @@
 %!PS-Adobe-3.0
 %%Creator: Basser Lout Version 3.36 (July 2007)
-%%CreationDate: Thu May  8 17:59:09 2008
+%%CreationDate: Thu May  8 18:03:00 2008
 %%DocumentData: Binary
 %%DocumentNeededResources: (atend)
 %%DocumentSuppliedResources: (atend)
@@ -13698,7 +13698,7 @@
 po: PS_RestoreGraphicState returning.
 po: PS_RestoreGraphicState()
 po: PS_RestoreGraphicState returning.
-po: PS_LinkDest("targets", 480, 11167, 480, 11167)
+po: PS_LinkDest("targets", 0, 11167, 0, 11167)
 po: PS_LinkDest returning.
 po: PS_LinkDest("19.4580.det_gall.1", 6040, 10687, 6040, 10902)
 po: PS_LinkDest returning.
@@ -23581,7 +23581,7 @@
 po: PS_PrintGraphicObject returning
 po: PS_RestoreGraphicState()
 po: PS_RestoreGraphicState returning.
-po: PS_LinkDest("font", 2268, 11793, 2268, 11793)
+po: PS_LinkDest("font", 0, 11793, 0, 11793)
 po: PS_LinkDest returning.
 po: PS_LinkDest("19.4580.pre_font.1", 728, 11313, 728, 11530)
 po: PS_LinkDest returning.
@@ -25181,7 +25181,7 @@
 1455(ending,)s 2213(whether)s 3043(or)s 3302(not)s 3667(at)s
 3899(the)s 4246(end)s 4650(of)s 4921(a)s 5086(line,)s
 5551(one)s 5952(e)s 3(xtra)k 6486(space)s 7073(is)s
-7282(added.)s 8018(A)s 8247(sentence)s 0 12257(ending)m 709po: 
PS_LinkDest("yunit", 145278000, 10319, 145278000, 10319)
+7282(added.)s 8018(A)s 8247(sentence)s 0 12257(ending)m 709po: 
PS_LinkDest("yunit", 0, 10319, 0, 10319)
 po: PS_LinkDest returning.
 po: PS_LinkDest("19.4580.pre_yuni.1", 1741, 9839, 1741, 10054)
 po: PS_LinkDest returning.
@@ -27279,11 +27279,11 @@
 po: PS_LinkDest returning.
 po: PS_LinkDest("19.4580.pre_hshi.1", 1802, 5597, 1802, 5812)
 po: PS_LinkDest returning.
-po: PS_LinkDest("16.1692.pre_hshi.1", 1450, 4804, 1450, 4804)
+po: PS_LinkDest("16.1692.pre_hshi.1", 0, 4804, 0, 4804)
 po: PS_LinkDest returning.
-po: PS_LinkDest("16.1692.pre_hshi.2", 720, 4299, 720, 4299)
+po: PS_LinkDest("16.1692.pre_hshi.2", 0, 4299, 0, 4299)
 po: PS_LinkDest returning.
-po: PS_LinkDest("16.1692.pre_hshi.3", 3783, 3506, 3783, 3506)
+po: PS_LinkDest("16.1692.pre_hshi.3", 0, 3506, 0, 3506)
 po: PS_LinkDest returning.
 2527(a)s 2699(length)s 3361(\(Section)s
 4220(3.2\))s 4655(whose)s 5329(unit)s 5768(of)s 6045(measurement)s
@@ -35420,7 +35420,7 @@
 1119(a)s 1278(medium)s 2115(space;)s 2751(others)s 3379(ha)s 4(v)k 3(e)k
 3873(a)s 4032(thin)s 4454(space)s 5034(on)s 5324(the)s
 5665(right)s 6169(only)s 15(.)k 6737(This)s 7206(w)s 2(ould)k
-7854(be)s 8129(easy)s 86po: PS_LinkDest("paras", 210, 2130, 210, 2130)
+7854(be)s 8129(easy)s 86po: PS_LinkDest("paras", 0, 2130, 0, 2130)
 po: PS_LinkDest returning.
 po: PS_LinkDest("19.4580.exa_para.1", 250, 1074, 250, 1291)
 po: PS_LinkDest returning.
@@ -35988,7 +35988,7 @@
 po: PS_LinkDest returning.
 po: PS_LinkDest("16.1692.exa_para.1", 0, 10933, 0, 10933)
 po: PS_LinkDest returning.
-po: PS_LinkDest("16.1692.exa_para.2", 720, 9865, 720, 9865)
+po: PS_LinkDest("16.1692.exa_para.2", 0, 9865, 0, 9865)
 po: PS_LinkDest returning.
 po: PS_LinkDest("16.1692.exa_para.3", 0, 5629, 0, 5629)
 po: PS_LinkDest returning.

reply via email to

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