Discussion:
[tex-k] Total number of words in pltotf
Hironobu Yamashita
2017-09-09 20:48:07 UTC
Permalink
I found a problem in 'pltotf' program:

When huge LIGKERN program is used like this (lklarge0.pl),
https://gist.github.com/aminophen/c8b7c2bc3e0d28b11b365b7896bfebbb

'pltotf' does not complain about it but both 'tftopl' and 'tex'
complains about the output TFM:

$ pltotf lklarge0
$ tftopl lklarge0 temp
The first byte of the input file exceeds 127!
Sorry, but I can't go on; are you sure this is a TFM?
$ tex "\font\x=lklarge0 at 10pt\x A\bye"
! Font \x=lklarge0 at 10.0pt not loadable: Bad metric (TFM) file.

What is worse, 'uptftopl' fails to allocate memory for huge
GLUEKERN table like this (gklarge0.pl),
https://gist.github.com/aminophen/2839eb95e33d8c0d450c2ef8c8f8967d

$ uptftopl gklarge0 temp
Input file is in YOKO-kumi kanji tfm format.
uptftopl(17192,0x7fff760ef000) malloc: *** mach_vm_map(size=18446744073709428736) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
fatal: memory exhausted (realloc of 18446744073709426269 bytes).

The reason for both problems seems to lie in pltotf.web, which
does not test whether lf (total number of words) exceeds 2^{15},
which results in negative number.

By adding (for web2c compiler)

if lf<1 then begin
print_ln('The total number of words in the TFM file too large!');
uexit(1);;
end

at the end of @<Compute the twelve...@>= routine, these problems
can be avoided.

Best,
Hironobu Yamashita
Hironobu Yamashita
2017-09-09 21:43:27 UTC
Permalink
Post by Hironobu Yamashita
What is worse, 'uptftopl' fails to allocate memory for huge
GLUEKERN table like this (gklarge0.pl),
https://gist.github.com/aminophen/2839eb95e33d8c0d450c2ef8c8f8967d
$ uptftopl gklarge0 temp
Input file is in YOKO-kumi kanji tfm format.
uptftopl(17192,0x7fff760ef000) malloc: *** mach_vm_map(size=18446744073709428736) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
fatal: memory exhausted (realloc of 18446744073709426269 bytes).
The origin of the above error itself should be also resolved,
so I'll add a check of lf<2^{15} into ptftopl.ch.

Hironobu Yamashita
Hironobu Yamashita
2017-09-10 04:17:07 UTC
Permalink
Post by Hironobu Yamashita
When huge LIGKERN program is used like this (lklarge0.pl),
https://gist.github.com/aminophen/c8b7c2bc3e0d28b11b365b7896bfebbb
'pltotf' does not complain about it but both 'tftopl' and 'tex'
$ pltotf lklarge0
$ tftopl lklarge0 temp
The first byte of the input file exceeds 127!
Sorry, but I can't go on; are you sure this is a TFM?
$ tex "\font\x=lklarge0 at 10pt\x A\bye"
! Font \x=lklarge0 at 10.0pt not loadable: Bad metric (TFM) file.
The problem seems specific to web2c implementation of pltotf.
In pltotf.web, we find

@!lf:0..32767; {the number of words in the entire \.{TFM} file}

however, web2c converts this into

short lf ;

This conversion mistakenly allows 'lf' to overflow, and it ends
up generating invalid TFM file. I hope the attached patch can
be safely applied to pltotf.ch.

Hironobu Yamashita
Karl Berry
2017-09-10 21:24:43 UTC
Permalink
This conversion mistakenly allows 'lf' to overflow, and it ends
up generating invalid TFM file.

I suppose we could somehow make it convert to unsigned short, but that
wouldn't help in general, since it could still be longer than 16
bits. And trying to use uint16_t will surely cause endless compatibility
problems to ensue, so forget that.

I hope the attached patch can be safely applied to pltotf.ch.

It looks fine to me. In principle it would be nice to include the
erroneous value in the error message, but since TeX programs are usually
lacking in that regard, it's no biggie.

Thanks,
Karl

Loading...