Comparison is always false errors in tftopl and vftovp
C.M. Connelly
When building tetex 1.0.6, tftopl and vftovp trigger ``comparison
is always false due to limited range of data type'' warnings from
the gcc 2.95 compiler, indicating a bug in the code. This bug
means that if a TFM file has more than 32510 ligkern entries,
instead of dying with an error message, tftopl and vftovp will
overflow various arrays.
The code causing these errors is identical in both files:
if nl>4*lig_size then
abort('The lig/kern program is longer than I can handle!');
(See line 482 of tftopl.web and line 644 of vftovp.web.)
As I understand it, there is no reason for multiplying lig_size by
four -- this code *should* read:
if nl>lig_size then
abort('The lig/kern program is longer than I can handle!');
Both nl and lig_size measure the size of the lig/kern program in
words. Quoting the source, nl is defined as
|@!nl|&number of words in the lig/kern table;\cr
(line 150 in tftopl.web; line 313 in vftopl.web), and the .ch
files set lig_size to be
@!lig_size=32510; {maximum length of |lig_kern| program, in words}
(line 68 in tftopl.ch; line 55 in vftopl.ch)
CMC
P.S. This bug came to light as part of the Debian Project's effort
to fix warnings generated by code that assumes char is always
signed -- while that assumption holds for x86 architectures (among
others), it's not true for PowerPC (and other) architectures, and
generates the same comparison always false warning from gcc.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Behind the counter a boy with a shaven head stared vacantly into space,
a dozen spikes of microsoft protruding from the socket behind his ear.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
C.M. Connelly c...@eskimo.com SHC, DS
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
C.M. Connelly
OW> I'm not certain there are valid tfm files with [32510
OW> lig/kern] entries, in part because of the problem you
OW> mention. But I agree with your diagnosis. Which means
OW> you're correct that the multiplication is not correct here:
The problem would be more likely to show up with Knuth's original
value for lig_size of 5000, but even then it's pretty unlikely
that there are many fonts with more than 20,000 ligatures and
kerns.
OW> The problem will have to be reported to DEK, of course,
OW> since it is part of the original web files (section 21 of
OW> TFtoPL, section 25 of VFtoVP). I've added Maggi McLoughlin
OW> so she can bring this to his attention.
OW> Are you the one who found the problem? I'd like to ensure
OW> proper attribution.
Yes. To be fair, I wouldn't have been looking into the problem if
Daniel Jacobowitz <d...@debian.org> hadn't mentioned on the Debian
PowerPC mailing list that Debian's tetex-bin package had problems
that prevented it from being automatically uploaded by the PowerPC
build daemon.
As far as I know, I'm the first person to look into this problem.
I did a Google search and checked Deja and the archives of tex-k
before writing.
My housemate, Melissa O'Neill <one...@cs.sfu.ca>, was a huge help
in tracking down the exact etiology of the bug -- I was initially
looking at nl being defined as a short (in the C code) as the
source of the problem rather than realizing that the problem was
actually the multiplier for lig_size.
CMC
Maggie McLoughlin
She will hold them for the next time I have time to look at them ---
I always do "batch processing" instead of "swap-in-swap-out".
Also, I hate to disappoint whoever found this anomaly, but there
is no monetary reward for bugs in TeX/MFware programs like tftopl,
only for bugs in TeX or MF themselves. (I do however, write a
note of appreciation and stamp it in gold with the TeX lion; maybe
that's worth something...)
Also, this may not be a bug at all, since Pascal does arithmetic
more sensibly than C (hence it might be a Web2C problem). But it
probably indeed is a mistake and my fault. I'll know for sure when
I have time to look at such things.
Thanks anyway for being a multipurpose server, while I'm offline! -- Don