TeX 3.14159 and other updates -- file 1 of 2 This and the following messages contain the details of bug reports sent to Don Knuth, edited somewhat for brevity, and his responses. As already announced, the new release -- TeX 3.14159, MF 2.718 and related TeX- and MFware -- is at labrea.stanford.edu in the file ~ftp/alpha/tex95.tar.gz . No arrangements have been made yet to install the unpacked versions into the /tex area at labrea, from which it can be mirrored to CTAN; I will try to do that as soon as possible. This message begins with a complete contents list of the main topics in this collection, to help you find items of interest quickly. I have just sent out the reward checks with the annotated originals of the reports as Don returned them to me. They should be arriving at their destinations soon. ######################################################################## Contents: >>> TeXbook / MFbook / documentation bugs +++ glitch in errata.five at labrea +++ MFbook, page 134 and others from Robert Hunt +++ MFbook, page 143 +++ MFbook, several from Denis Roegel +++ Spurious TAB in errorlog.tex >>> The TeX program +++ trap_zero_glue bugette +++ font_mem_max and other memory parameters [ continued in file message.045 ] >>> plain.tex +++ \oalign and \d{} +++ hyphenation inhibited by struts +++ TeXbook, page 363, in \endinsert >>> Metafont +++ arithmetic overflow with z=whatever[z',z''] +++ several reports from Bogus{\l}aw Jackowski >>> CM fonts +++ missing "cmchar"s in bigdel.mf +++ shaved_stem vs. cap_stem in greeku.mf +++ miscellanea from Robert Hunt, mostly in CM sources +++ cap_ess in cmmi12 and larger +++ possible glitch in cmbx5 and cmbx6 +++ arithmetic overflow in CMinch +++ sterling sign >>> Fontware +++ testfont.tex +++ VPtoVF ************************************************************************ [ dek -- Robert Hunt: C134 $2.56, C207 $2.56, C257 $2.56, A354 $2.56, A359 $2.56, A360 $2.56, A361 $2.56, A362 $2.56, A362 $2.56, E95(97) $2.56, E187 $2.56, E113 $2.56, E233 $2.56, E438 $2.56, C129 $2.56, E491 $2.56 Chris Thompson: C206 $2.56, TeX\S549 $327.68 Michael Barr: A357 $2.56 Peter Schmitt: C143 $.32 Marek Ry\'cko: A31 $2.56 Bogus\l{}aw Jackowski: MF\S815 $327.68, CSCSPU bugfix $2.56 Denis B. Roegel: C94 $2.56, C107 $2.56, C355 $2.56 Eberhard Mattes: TeX\S634 $2.56 Jim Sterken: TeX\S625 $2.56 Rainer Schoepf: B503 $2.56 Bernd Raichle: A374 $.32 Barbara Beeton: C354 $2.56 Berthold Horn: TeX\S1323 $20.48 Pierre MacKay: E291 $.32 Walter Carlip: TeX\S717 $10.24 Andrew K. Trevorrow: TeX\S549 $20.48 Yannis Haralambous: E239 $2.56 J"org Knappen: A356 $2.56 Petr Sojka: A356 $2.56 Ulrik Vieth: A363 $2.56 ] >>> TeXbook / MFbook / documentation bugs +++ glitch in errata.five at labrea in errata.five: \bugonpage C282, the three lines following the chart (9/39/89) should be ^ \bugonpage C282, the three lines following the chart (9/30/89) [ dek * ] ---------------------------------------------------------------------- +++ MFbook, page 134 and others from Robert Hunt Date: Thu, 16 Apr 92 15:57:44 BST From: Chris Thompson To: Barbara Beeton Cc: Robert Hunt Subject: MFbook p.134 bug from Robert Hunt Here is another one from Robert: > MFbook, page 134 (line 7933 of mfbook.tex) should read > ...if $t\le 0$, precontrol~$t$ of~$p$ is~$z_0$. > (rather than $z_n$). [ dek -- $2.56 ] He's right. The z_n has somehow got duplicated from the previous sentence. Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1@phx.cam.ac.uk ------- Date: Thu, 07 May 92 22:37:53 BST From: Chris Thompson To: Barbara Beeton Cc: Robert Hunt Subject: Miscellany from Robert Hunt Barbara, Here are three things from Robert Hunt (his messages to me marked with ">"): 1. (7 May): [ this has been resolved already ] 2. (22 Apr, after I had been publicising the errata.* files locally): > Is there any way of telling how far back it's necessary to go through > the "Bugs in Computers and Typesetting" files in order to make sure > that you have all the necessary changes? I very recently bought a copy > of the softback version of the METAFONTbook, which says "6th printing, > revised, February 1991" inside; but some of the changes listed in even > only the third file (which covers the period up to June 1987) have not > been made to it. As a typical example, the correction to page 14 (to > mention Paul de Casteljau as the discoverer of the recursive midpoint > rule) has not been made; but the correction to page 348, to include > his name in the index, has! The same is true of the bugs listed in the > fourth file and so on, which makes the book somewhat inconsistent in > places. Is it possible that the printers have accidentally lost some > of the updates, perhaps? [ dek -- yes AW totally screwed this up and i was bl**dy *ngry ] I must admit I didn't entirely believe this until Robert actually turned up with his copy of the book today: the example he gives is certainly correct. Very odd. Do you know whether anything more than usually peculiar happened to the 6th softcover printing? (The current mfbook.tex at labrea purports to represent the 7th softcover printing.) If not, who could answer Robert's questions? 3. (7 May): > My candidate for the most trivial error in the METAFONTbook: on page > 207, line 10, "-.00005" should read "-0.0005". Yes, that is an error, not yet fixed in mfbook.tex. But I'm sure we can find one yet more trivial, can't we? ... Actually, I tried to reproduce the numbers on pages 206-207 by [ dek -- $2.56 ] compiling io.mf (from labrea) with mode=lowres;autorounding:={0 or 1}; tracingspecs:=1 and I get numbers a teeny bit different from what is in the text. For example, instead of "point (10.85146,-0.0005), where there was a horizontal tangent, has been rounded to (10.85872,0)", I get (10.85147,-0.00049) and (10.85873,0). Maybe the rounding details in MF have changed since DEK did the run that produced these numbers. [ dek -- $2.56 Yes that was either bug #550 or 560. or both ] Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1@phx.cam.ac.uk ------- Date: 19 May 1992 22:50:35 -0300 (BST) From: Chris Thompson Subject: Yet another MFbook bug from Robert Hunt Barbara, The following from Robert Hunt (11 May; I was ill last week and am only now getting round to clearing some of the backlog): [ dek -- (and here i sit on a chilly day in California 26 Feb 199_5_, coughing as I try to reduce the _secondary_ backlog.) Hope you're feeling better by now, Chris! ] > On page 257 of the METAFONTbook, line 5 (the large centred display), > the bracketed entries |numeric| |<| |numeric| (etc.) should read > \ |<| \ instead. [ dek -- $2.56 (maybe should be $2.57 instead?) ] He's right: the two stacks (boolean, numeric, pair, string, transform) should be <...> types, not boldface words, for consistency with the rest of Appendix B. Not fixed in the latest mfbook.tex available to me. Chris Thompson ------- [ dek -- However -- Why was I not told this in 1992 or 1993? I could then have fixed the final printing of MFbook. Changes since 93 affect the electronic copy _only_; the hardcopy is frozen now for vols A, B, C, E. ] ---------------------------------------------------------------------- +++ MFbook, page 143 Date: Thu, 08 Jul 93 15:03:58 MEZ From: Peter Schmitt To: INFO-TEX <@cunyvm.cuny.edu:INFO-TEX@SHSU.BITNET> Subject: bugs in MFbook and TeXbook Since this topic is just discussed: I recently noticed two `bugs' in the MFbook which --- as far as I could see from the Errata --- have not yet been corrected: %%%% The METAFONTbook Fourth printing, revised, September 1991 [ first one has been fixed ] page 143, line 2 : `giving the next exprs:' should read `giving the next expressions:' %%%% [...] Peter Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at schmitt@awirap.bitnet ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 [ dek -- great name ^^^^^^^^^^^^^^ ] University of Vienna A-1090 Wien Austria ------- Date: 08 Jul 1993 15:37:56 -0300 (BST) From: Chris Thompson To: Peter Schmitt Subject: Re: [bugs in MFbook and TeXbook] Reply to Peter Schmitt, copied to Barbara Beeton. [...] > page 143, line 2 : `giving the next exprs:' > should read `giving the next expressions:' > %%%% This is unchanged in the most recent mfbook.tex available to me. It does read rather oddly. I wonder whether the 'expr' was meant to be in \tt? [ dek -- 32\cents ] Chris Thompson ------- [ dek -- Not an error -- when you input _expr.mf_ the computer types _``Gimme an expr: ''_ and I was just appropriating that neologism into English. Like `ftp' and `grep'. However I do admint that a reasonable person might wonder at my idiosyncratic style, so I'll change to \tt and pay the normal reward of 32\cents for suggestions. ] ---------------------------------------------------------------------- +++ MFbook, several from Denis Roegel Date: 04 May 1994 16:58:42 +0200 From: "Denis B. Roegel" Cc: roegel@lorraine.loria.fr (Denis B. Roegel) Subject: bugs in the METAFONTbook Mrs Beeton, I found two small bugs in my copy of the METAFONTbook (hardcopy). I went through the last erratas and found no mention of them. Here they are: 1) page 94: last paragraph, 4th line: the word "are" is duplicated. [ dek -- $2.56 ] 2) [resolved ] Thak you, Denis. (roegel@loria.fr) ------- Date: 05 May 1994 17:14:40 +0200 (MET DST) From: "Denis B. Roegel" Subject: Re: bugs in the METAFONTbook [...] Maybe there is another bug in the MFbook: In the first paragraph of page 115, the instruction "endchar" in the program at the end of chapter 12 is mentionned. However, there is no "endchar" in the program at the end of chapter 12. [ dek -- $2.56 page 107 ] Denis. ------- (reply, 05 May 1994) thanks for your additional report. the "dangerous bend" program in the file manfnt.mf is just a bit different from what is in the mfbook, and does end with an "endchar" -- preceded by another line not in the mfbook. for some reason, this bug (i'm sure it is!) sounds familiar to me, but i can't find a reference, and it's not corrected in any of the errata files. onto the dek list it goes ... cheers. -- bb ------- ---------------------------------------------------------------------- +++ Spurious TAB in errorlog.tex [ from comp.text.tex, 21 Jan 95 ] Date: 20 Jan 1995 12:38:36 GMT From: schwab@issan.informatik.uni-dortmund.de (Andreas Schwab) Subject: Spurious TAB in errorlog.tex There is a spurious TAB in the file systems/knuth/errata/errorlog.tex, as found on the CTAN, in line 2867, containing the text "(Mattes and Raichle). @1036". This TAB (after the word Mattes) causes a Greek Psi [ dek * ] to be typeset where a space should have been, looking a bit funny :-). -- Andreas Schwab "And now for something schwab@issan.informatik.uni-dortmund.de completely different" =========================================================================== [ dek -- _Thanks_ ] <<< end TeXbook / MFbook / documentation bugs ************************************************************************ >>> The TeX program +++ trap_zero_glue bugette Date: 28 Oct 1993 16:26:02 +0000 (GMT) From: Chris Thompson To: Rainer Schoepf Subject: Re: [interesting effect in overfull box printout] Rainer, Yes, I think you have discovered a bugette. CC'ing this to Barbara. You write (omiting the history as to why you were changing latex.tex) > > Studying TeX the program I found what I think is an oversight: > whenever a glue node is generated, either when scanning a glue > specification in assignment, as well as in glue register arithmetic, > the procedure trap_zero_glue is called to replace references to zero > glue to a reference to the special object zero_glue. Actually, this is a bit too strong. |trap_zero_glue| is only called when setting a `glue register or parameter', as the preamble to section 1229 says. For example, in \setbox0=\hbox{Foo\hskip 0pt plus 0pt minus 0pt Bar} the glue node doesn't point to |zero_glue|, but to a private |glue_spec| with zero contents. > The only > exception to this rule is scanning the glue specification after > \tabskip in preparation of an alignment preamble. Therefore, > > \tabskip=\z@ > > generates a new glue node with zero fields, whereas > > \tabskip=\z@skip > > generates only a reference to zero_glue. I agree. This breaks the invariant promised in #1229. [ dek -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ] > Now, since the overfull box > printer checks only for equivalence with zero_glue, a blank is printed > in the first case. [The code in |short_display| (section 175)] > The only other difference I could find is in TeX's > processing of alignment entries: in a certain case the tabskip glue > reference is replaced by zero_glue unless it is already zero_glue, > i.e. this code is executed without it really being necessary. I can find no way other than |short_display| of making the difference visible, which is why I call it a bugette rather than a bug. Some glue parameters are tested for being zero by pointer comparison with |zero_glue|, but \tabskip isn't one of them. > I cannot think of a reason why this behaviour should influence > anything other than the overfull box printing, yet I think it should [ dek -- also tracingparagraphs \S857 ] > be changed in the next update to tex.web. It seems to me that a simple > call to trap_zero_glue should suffice. Specifically, in |get_preamble_token|, section 782. There will need to be a forward declaration of |trap_zero_glue| as well. [ dek -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ] > What do you think? I think it should go on Barbara's list for Don. Chris Thompson ------- Date: 28 Oct 1993 17:39:56 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) To: Chris Thompson Cc: Barbara Beeton , Rainer Schoepf Subject: Re: [interesting effect in overfull box printout] Chris, I wrote: > > The only other difference I could find is in TeX's > > processing of alignment entries: in a certain case the tabskip glue > > reference is replaced by zero_glue unless it is already zero_glue, > > i.e. this code is executed without it really being necessary. to which you replied: > I can find no way other than |short_display| of making the difference > visible, which is why I call it a bugette rather than a bug. I agree. > Some > glue parameters are tested for being zero by pointer comparison with > |zero_glue|, but \tabskip isn't one of them. But it is, in the piece of code labelled [ dek -- ---? that's _not_ a pointer comparison to zero_glue ] If I understand this correctly, the local variable s points to a copy of the tabskip glue of that point. But that doesn't influence the outcome in any way. ------- Date: 28 Oct 1993 18:06:22 +0000 (GMT) From: Chris Thompson To: Rainer Schoepf Subject: Re: [interesting effect in overfull box printout] Rainer, > > Some > > glue parameters are tested for being zero by pointer comparison with > > |zero_glue|, but \tabskip isn't one of them. > > But it is, in the piece of code labelled > > > > If I understand this correctly, the local variable s points to a copy > of the tabskip glue of that point. But that doesn't influence the > outcome in any way. Maybe I expressed that wrongly. I meant that there were no cases of comparing \tabskip directly out of |equiv(glue_base+tab_skip_code)| with |zero_glue|, in the way that there is for \spaceskip and \xspaceskip in |main_control|, for example. The code in section 802 that you mention is comparing glue copied from \tabskip (sharing its |glue_spec|, admittedly) and as you say it doesn't effect the outcome, as the test against the glue already being |zero_glue| is only an optimization and could be omitted entirely. Chris Thompson Internet: cet1@phx.cam.ac.uk JANET: cet1@uk.ac.cam.phx ------- [ dek -- I hesitate to change anything here, on the off chance that I did have a reason for the ``redundant'' code in \S802 ... something way back in my memory warns me to leave this alone. I will just change the slightly-false comment in \S1229. Of course I am 99.9999% certain that I could safely make the change you suggest, but it is a big pain to handle the forward referencing [I probably would put \S1229 into a section of its own named Declare the procedure trap_zero_glue, and place that in 782.] -- requires reprinting many pages of the book. Much too much trouble for very little gain at this late late stage. ] ---------------------------------------------------------------------- +++ font_mem_max and other memory parameters Date: 17 Dec 1993 16:01:52 -0500 (EST) From: Berthold Horn <71172.524@CompuServe.COM> Subject: Re: where to send bug report Dear Barbara: [...] [ dek * ] (1) OK, here it is. I don't know whether to call it a `real' bug since it only comes up if one implements Knuth's scheme for growing main memory in TeX (which is why TeX implementers haven't run into it before --- except possibly Barry Smith? with Textures). But then Knuth did describe how it is supposed to work... In 174 (page 71 of `TeX: the program') it should say: begin while p \ne null do [ dek -- No this is not robust in the presence of clobbered lists -- You are asking me to _undo_ one of the important corrections I made years ago. ] instead of: begin while p > mem_min do On machines with fixed main memory (or in iniTeX), these happen to be equivalent because` mem_min' is zero, just as `null' is zero. But when [ dek -- ?? null is -30000 on my system at home, for instance. ] memory grows downwards, then `mem_min' is negative, and one can get caught in a delightful infinite loop while looking for the null at the end of a list! The same problem occurs in 182 (page 74), Fortunately nowhere else. An alternate `fix' would be to redefine null to be the same as memmin, but that would be a very poor solution since in dynamic allocation, mem_min changes from time to time. (2) While I have your attention, I'd like to complain about a recent implementaiton decision that is a pain for dynamic memory allocation. For `bcharlabel' is used `fontmemptr'. For a system with fixed allocations, this is a reasonable [ dek - ^^^ size ] way to say this doesn't point to any valid font, but its no good if font memory can grow. I replaced this with `maxhalfword', which is fixed. Plus, when a format file is read in, I try and figure out what value of fontmemptr was used when it was dumped and replace that with `maxhalfword'. Its important for a format file not too have too many frozen in dependencies on allocations. One should be able to handle at least variations in size of main memory, string pool size, font memory size, hyphenation table size etc. (3) By the way, I am wondering why we still seem to be using maxhalfword = 262144 when there aren't really any 36 bit machines left (been I while since I hacked on a PDP6 or PDP10 :=), and everyone is using [ dek -- ^^^^^^^^ in fantasy land ] 64 bit words. Doesn't make sense in a 32 bit address space world... (4) Finally, I'd like to recommend that --- given that we are using 64 bit words --- the TeX 82 limitation in fontmax == 256 be lifted. We did this in Y&YTeX on [ dek -- ^^^^^^^^^ This would break the _Pascal_ implementation that still exists, I think? ] an experimental basis and it involves only a tiny change where font definitions are written to the DVI file, and a tiny change where font changes are written to the DVI file. DVI processors are already supposed to be able to understand the multi-byte font commands (despite the fact that TeX 82 never generates them) - although, the `level 0' standard does allow them to support only 256 internal font numbers (a weird and wonderful contraction if you ask me). [...] [ dek -- These things are up to implementors' discretion. Something in the back of my mind triggers a caution flag -- not only in the memory for hyphenation but also in the \span feature of alignments, I fear (?) Good luck. ] Berthold & Blenda. ------- Date: 09 Mar 1994 16:59:50 -0500 (EST) From: andrew.trevorrow@anu.edu.au (Andrew K Trevorrow) Subject: new TeX bug Hi Barbara, I think I've found a bug in TeX. Please pass on the following note to the TeX implementors to verify my analysis. ---------------- Over the last couple of years a few OzTeX users have reported a strange bug in which a character at the start of a word changes for no obvious reason. I was never able to reproduce the problem until the other day when Ole Michael Selberg sent me the vital clue: the problem only happens if font_mem_size is increased and the format file is NOT rebuilt. (OzTeX users don't have to recompile TeX to change font_mem_size; they simply edit a number in a configuration file.) Now font_mem_size is supposed to be one of the parameters that can differ in INITEX and VIRTEX. The problem is that non_address is set to font_mem_size, so when bchar_label[f] values are set to non_address and stored in a format file by INITEX they will not be recognized as non-address values by a VIRTEX that uses a different font_mem_size! Note that if font_mem_size in VIRTEX is smaller than the INITEX value then a fatal format error will occur when loading bchar_label[nullfont] (which was set to non_address by INITEX). If font_mem_size in VIRTEX is larger than the INITEX value then far nastier problems can occur, such as a character at the start of a word changing. One solution would be to treat font_mem_size like hash_size and the other parameters that require format files to be rebuilt if their values change. A better solution is to set non_address to -1; this allows font_mem_size to be different in INITEX and VIRTEX. Here are the changes needed to tex.web: @x @!font_index=0..font_mem_size; {index into |font_info|} @y @!font_index=-1..font_mem_size; {index into |font_info|} @z [ dek -- Now many compilers will refuse to pack properly ] @x @d non_address==font_mem_size {a spurious |font_index|} @y @d non_address==-1 {a spurious |font_index|} @z @x if bchar_label[hf]non_address then {put left boundary at beginning of new line} @z @x undump(0)(font_mem_size)(bchar_label[k]); @y undump(non_address)(font_mem_size-1)(bchar_label[k]); @z I've included these changes in a new version of OzTeX and they fix the bug. Andrew Trevorrow akt150@huxley.anu.edu.au ------- Date: 09 Mar 1994 11:08:17 -0500 (EST) From: Louis Vosloo <71172.524@CompuServe.COM> Subject: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] Dear Barbara: I believe I already reported on this problem. font_mem_max is used [ dek -- ^^^ size ] as a special value for bchar etc. Which is fine if font_mem_max never changes, but for a `dynamic' TeX (like Y&YTeX) this doesn't work. My solution was to change this to max_half_word. In addition, my format undumping code tries to figure out what value was used in the dumped format and then replaces that systematically with max_half_word. That way it can handle `old' format files made before the fix as well. Berthold K.P. Horn 71172.524@compuserve.com ------- Date: 09 Mar 1994 11:25:40 -0500 (EST) From: Berthold Horn <71172.524@CompuServe.COM> Subject: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] Dear Barbara: The following is extracted from email I sent to you on 93/Dec/17. The bug reported by Trevor is mentioned below in item (2) Regards, Berthold. ... (1) OK, here it is. I don't know whether to call it a `real' bug since it only comes up if one implements Knuth's scheme [...] [ remainder of message as above ] ------- Date: 09 Mar 1994 17:02:14 +0000 (GMT) From: Chris Thompson To: Barbara Beeton Cc: Andrew Trevorrow Subject: Andrew Trevorrow's new TeX bug Barbara, I am replying directly to you rather than to the tex-implementors list, with a copy to Andrew. > ... as soon as the problem has > been verified, i'll forward it to knuth. (it's getting to be > time for his annual tex-inspection tour.) [ dek -- ^^^^^^ exponentially decreasing, actually, although I am one year behind plan (not two) ] About time :-) It gets later every year... [ dek -- \check ] > Now font_mem_size is supposed to be one of the parameters that can differ in > INITEX and VIRTEX. The problem is that non_address is set to font_mem_size, > so when bchar_label[f] values are set to non_address and stored in a format > file by INITEX they will not be recognized as non-address values by a VIRTEX > that uses a different font_mem_size! > > Note that if font_mem_size in VIRTEX is smaller than the INITEX value > then a fatal format error will occur when loading bchar_label[nullfont] > (which was set to non_address by INITEX). If font_mem_size in VIRTEX is > larger than the INITEX value then far nastier problems can occur, such as > a character at the start of a word changing. Yes, this is a bug, and a quite nasty one too. Introduced by the changes in TeX version 3, so presumably Andrew only gets the smaller reward. [ dek -- (Berthold) ] > One solution would be to treat font_mem_size like hash_size and the other > parameters that require format files to be rebuilt if their values change. > A better solution is to set non_address to -1; this allows font_mem_size to > be different in INITEX and VIRTEX. Putting |non_address| at the other end of the range seems to be the right solution. I think it could equally well be set to 0 as to -1. [ dek -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ] The values in the |bchar_label| array can never be this small naturally: they are true indices into |font_info| rather than offset ones. There is a technical problem about making this change to TeX. One needs [ dek -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ] to force old format files to be invalid, because the |non_address| values in them would be wrongly interpreted (even more so than at present, that is!). This wouldn't happen "naturally". My MVS version of TeX has hacks to make |font_index| a signed 16-bit value, starting at |font_mem_base| (currently dumped in the format file) rather than zero. I can foresee myself having to rework this... Chris Thompson Cambridge University Computing Service ------- Date: 09 Mar 1994 13:04:02 -0500 (EST) From: bbeeton To: CET1@phx.cam.ac.uk Cc: BNB@MATH.AMS.ORG, andrew.trevorrow@anu.edu.au Subject: Re: Andrew Trevorrow's new TeX bug chris and andrew, berthold horn has reminded me that he reported this bug in december; i did forward his message to you then, chris, but it seems to have got lost. attached is the forwarded message, along with some of today's commentary from berthold. he avers that setting non_address to -1 won't work under certain circumstances, and proposes another solution that does work for him. this seems to be more contentious than i expected. perhaps a wider discussion is warranted -- i've already received (but not read) a few other messages on the subject, including one from peter breitenlohner. cheers. -- bb -------------------- Date: 17 Dec 1993 16:27:33 -0500 (EST) From: bbeeton To: cet1@cus.cam.ac.uk Subject: [Berthold Horn <71172.524@CompuServe.COM>: Re: where to send bug report] chris, would appreciate it if you could verify this bug report, and perhaps comment on the other points made in the message. best wishes for the holidays. -- bb --------------- Date: 17 Dec 1993 16:01:52 -0500 (EST) From: Berthold Horn <71172.524@CompuServe.COM> To: bbeeton Subject: Re: where to send bug report Dear Barbara: [...] (1) OK, here it is. I don't know whether to call it a `real' bug since it only comes up if one implements Knuth's scheme [...] [ remainder of message as above ] -------------------- Date: 09 Mar 1994 11:08:17 -0500 (EST) From: Berthold Horn <71172.524@CompuServe.COM> To: bbeeton Subject: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] Dear Barbara: I believe I already reported on this problem. font_mem_max is used as a special value for bchar etc. Which is fine if font_mem_max never changes, but for a `dynamic' TeX (like Y&YTeX) this doesn't work. My solution was to change this to max_half_word. In addition, my format undumping code tries to figure out what value was used in the dumped format and then replaces that systematically with max_half_word. That way it can handle `old' format files made before the fix as well. Berthold K.P. Horn 71172.524@compuserve.com ------- Date: 09 Mar 1994 18:39:51 +0000 (GMT) From: Peter Breitenlohner To: bbeeton Subject: Re: [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug] Barbara, 1. this is definitely a bug 2. The fix is no good (incomplete). There is at least one place in tex.web which now says if bchar_label[hf] To: Barbara Beeton , Chris Thompson , Andrew Trevorrow , Berthold Horn <71172.524@compuserve.com> Subject: andrews bug et alia hi barbara (and chris, andrew, berthold), thanks for sending the various remarks, here my comments. 1. andrews bug yes, this definitely is a bug [...] since font_mem_size is among those parameters that are explicitely allowed to differ between VIRTEX and INITEX. andrews fix is bad for two reasons a) the test ...non_address b) a bchar_label=-1 fails in undump where the value is tested to be in the range 0..font_mem_size. I did not think about Chris's point (invalidating old format files) but had changed the test in undump anyway (general neatness) and this pays [ dek - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ] nicely since it does catch the old formats that must be rebuilt when non_address is changed from font_mem_size to 0 (not -1) as I would recommend. I fully agree with Chris that non_address=0 is OK, and I strongly dislike the -1 for various reasons (among others it unnecessarily forces font_index to be signed instead of unsigned). I have looked into tex.web and am fully convinced that one can safely set non_address=0 since font_info[0] is occupied by the first of \nullfont's parameters. Here my proposed change: @x [30] m.549 l.10678 - bug fix @d non_address==font_mem_size {a spurious |font_index|} @y @d non_address==0 {a spurious left boundary char label} @z %--------------------------------------- @x [41] m.916 l.17965 - bug fix if bchar_label[hf]non_address then {put left boundary at beginning of new line} @z %--------------------------------------- @x [50] m.1323 l.24036 - bug fix undump(0)(font_mem_size)(bchar_label[k]); @y undump(0)(fmem_ptr)(bchar_label[k]); [ dek -- ^^ -1 ] @z %--------------------------------------- 2. berthold horns msg from Dec 17 ad 2: non_address=max_halfword is probably OK as well, I have not checked all implications. I prefer =0 and this has the definite advantage that it does catch old formats that need to be rebuilt. (Having to rebuild formats when the program changes - even if the pool checksum doesn't change - is certainly ok.) ad 3: that is entirely up to implementors, the 262144 never shows up in tex.web. But bigTeX has to set some reasonable limit on the size of the mem array otherwise a stupid paging system uses up enormous amounts of paging space and non-paging systems are completely sunk. Cetainly 256K is as good as any other number of the right size. ad 4: It would be tempting to increase font_max once max_halfword and max_quarterword have been increased. TeX uses at present only one-byte font numbers in the DVI file, i.e., range 0..255. Clearly TeX's dvi writing routines could certainly be adapted to a larger range, no problem here. But: Extending this range may have implications on existing DVI software. Some DVI drivers may rely on one-byte font numbers (re: driver standard?). Therefore I would be very careful at this point!! ad 1: I can't understand this problem. In VIRTEX mem_min must be <=mem_bot, [ dek -- Might have lots of stuff between mem_bot and mem_min, with a special allocation scheme ] and mem_min>=min_halfword=null. Now mem_bot is a glue spec, hence can never occur when traversing a list. If mem_min is mem_bot-1 or mem_bot-2 the one or two extra words are never used and if mem_minmem_min when traversing lists. It might be nicer to test for p<>null but I think this is no bug. Maybe only don knows why he has formulated this one test in a different way, but probably he forgotten the reasoning behind that. A bug might creep in if someone is dynamically extending the mem array during the run of VIRTEX and is not doing it properly (mimicking the behaviour of undump). I would say any problems introduced here are due to improper sys-dep modifications. [ dek -- \check ] regards peter ------- Date: 10 Mar 1994 12:57:35 +0000 (GMT) From: Chris Thompson To: Barbara Beeton Cc: Andrew Trevorrow , Peter Breitenlohner , Berthold Horn <71172.524@CompuServe.COM> Subject: Re: Andrew Trevorrow's new TeX bug Barbara, > berthold horn has reminded me that he reported this bug in december; > i did forward his message to you then, chris, but it seems to have > got lost. I found this message in an archive. Apologies: it arrived too late to be dealt with before Christmas, and got completely forgotten afterwards. If you have anything else outstanding on the potential bug list that I haven't replied to you about, please remind me a.s.a.p. > this seems to be more contentious than i expected. perhaps a wider > discussion is warranted -- i've already received (but not read) > a few other messages on the subject, including one from peter > breitenlohner. I agree with Peter Breitenlohner (personal communication) and with Bernd Raichle (in tex-implementors): there is absolutely no doubt that this is a bug. I don't think Wayne's position is defensible: I will post something to tex-implementors saying so. The main thing is to make sure the bug report is on the list for Don. We could argue about the merits of particular ways of fixing it until the cows come home, but it is Don who will actually make that decision. Peter, Andrew and I all seem happy with |non_address| = 0. Peter writes > ... I strongly dislike the -1 for various reasons (among others it > unnecessarily forces font_index to be signed instead of unsigned). (Although an alternative would be to make |bchar_label| an |integer| array rather than a |font_index| one.) Berthold suggests |non_address| = |max_halfword|, but I think this is not portable. While many implementations may squeeze |font_index| values into halfwords (indeed, I do myself) there is nothing in tex.web to prevent |font_mem_size| from being larger than |max_halford|. [ dek -- ^^ w ] (There is curiosity, though: |font_params| is an array of |halfword|s. Can one break TeX by setting \fontdimen? I will have to think about that one.) [ dek * ] I didn't intend my point about forcing the invalidation of old format files to be a big issue (there are many ways to achieve the desired effect): just something not to be forgotten. Andrew writes: > Maybe it would be a good idea to put some sort of version number (the > current TeX version?) in format files. I wonder if there is a spot > that would be guaranteed to catch all old formats? A suitable error > message would be "This is an old format file; use INITEX to rebuild > it.". It shouldn't be the TeX version number, because sometimes a version change does not require new format files, which is convenient when it happens. I have in the past fiddled with the 69069 at the end of the file to achieve deliberate invalidation in local implementations, but to get something like Andrew's message consistently one would want something right at the beginning. To take Berthold's 4 sections in order: 1. The |null| test. (I suspect that this is the only part of the message I even glanced at in December.) My first inclination is to agree with Peter's analysis, but I need to go through this in detail again. I will let you know. 2. = Andrew's bug, discussed above. 3. Why not |max_halfword| > 262144 ? This is a question relating to a particular implementation. 4. Why not |font_max| > |font_base| + 256 ? I have wondered about that myself. I don't think I can improve on Peter's analysis: > It would be tempting to increase font_max once max_halfword and > max_quarterword have been increased. TeX uses at present only > one-byte font numbers in the DVI file, i.e., range 0..255. Clearly > TeX's dvi writing routines could certainly be adapted to a larger > range, no problem here. > But: Extending this range may have implications on existing DVI > software. Some DVI drivers may rely on one-byte font numbers (re: > driver standard?). Therefore I would be very careful at this point!! No harm in suggesting it to Don, I suppose. If he doesn't like it, it is always open to an implementor to provide this extension via the change file. [ dek -- right ... see also \span (?) ] Chris Thompson Cambridge University Computing Service ------- Date: 10 Mar 1994 14:09:12 +0000 (GMT) From: Peter Breitenlohner To: Berthold Horn <71172.524@CompuServe.COM> Cc: Barbara Beeton , Chris Thompson Subject: Re: andrews bug et alia On 10 Mar 94 08:03:11 EST you said: > >Believe me, this very definitely *is* a bug! Think about what happens when >you extend the variable length node list downward. You can't very well then >go back over all list structures and change `null' to the new `mem_min'! > >> A bug might creep in if someone is dynamically extending the mem array >> during the run of VIRTEX and is not doing it properly (mimicking the >> behaviour of undump). I would say any problems introduced here are due to >> improper sys-dep modifications. > I think whenever you are dynamically allocating more mem-memory you should 1. never have mem_minmem_min => p<>null ) would be desirable [ dek -- no, it could cause p to go outside the array bounds. ] and would make life a little easier for those who want/have to dynamically enlage mem at the low end. I only disagree that this can be called a bug. The only point where standard TeX enlarges the low end of mem is when a format is read and VIRTEX's mem_min is below INITEX's mem_bot. And for this case Knuth's coding works fine, hence no bug [ dek -- _NB_: show_mode_list, short_display are designed to avoid crashing the system when TeX is buggy. See comment in \S182 ] regards peter ------- Date: 12 Mar 1994 12:30:55 +0000 (GMT) From: Peter Breitenlohner To: Andrew K Trevorrow , Barbara Beeton Subject: Re: andrews bug et alia Hi Andrew, Barbara On Sat, 12 Mar 94 14:14:40 EST you (andrew) said: > >By the way, I think that in your change to undump you should use >fmem_ptr-1 rather than just fmem_ptr (which is the first UNUSED index >in the font_info array). > To Andrew: That is indeed a good idea since it would catch old formats even in the rare event that fmem_ptr=font_mem_size! [ dek -- Actually I once noticed that "Web2C" omits the checking ... We must make sure this test is _not_ skipped. ] > To Barbara: can you please append the above to my messsage with the proposed fix. > regards peter ------- Date: 10 Mar 1994 17:03:39 +0000 (GMT) From: Chris Thompson To: Barbara Beeton Cc: Andrew Trevorrow , Peter Breitenlohner , Berthold Horn <71172.524@CompuServe.COM> Subject: Small TeX bug - \fontdimen Barbara, I wrote: > (There is curiosity, though: |font_params| is an array of |halfword|s. > Can one break TeX by setting \fontdimen? I will > have to think about that one.) There is, in fact, a bug here. The following code in TeX section 580, part of |find_font_dimen|, begin repeat if fmem_ptr=font_mem_size then overflow("font memory",font_mem_size); font_info[fmem_ptr].sc:=0; incr(fmem_ptr); incr(font_params[f]); until n=font_params[f]; contains no precautions to prevent |font_params[f]| from being incremented from |max_halfword|, its largest legal value. What happens next is implementation-dependant. In the case of the one I was experimenting with, |halfword| values wrap quietly from |max_halfword| to |min_halfword|, and so (for large enough |n|) the loop test is never satisfied, and one gets a font memory overflow condition (which is only mildly spurious). Possible fixes: make |font_params| an array of |integer|, or |font_index| (maybe: not sure about this), instead of |halfword|. Alternatively, in section 578 replace if n<=0 then cur_val:=fmem_ptr by if (n<=0) or (n>max_halfword) then cur_val:=fmem_ptr Chris Thompson Cambridge University Computing Service ------- Date: 12 Mar 1994 12:47:28 +0000 (GMT) From: Peter Breitenlohner To: Chris Thompson Subject: Re: Small TeX bug - \fontdimen On Thu, 10 Mar 94 17:03:39 GMT you said: >Barbara, > >I wrote: >> (There is curiosity, though: |font_params| is an array of |halfword|s. >> Can one break TeX by setting \fontdimen? I will >> have to think about that one.) > >There is, in fact, a bug here. The following code in TeX section 580, >part of |find_font_dimen|, > > begin repeat if fmem_ptr=font_mem_size then > overflow("font memory",font_mem_size); > font_info[fmem_ptr].sc:=0; incr(fmem_ptr); incr(font_params[f]); > until n=font_params[f]; > >contains no precautions to prevent |font_params[f]| from being >incremented from |max_halfword|, its largest legal value. What >happens next is implementation-dependant. In the case of the one >I was experimenting with, |halfword| values wrap quietly from >|max_halfword| to |min_halfword|, and so (for large enough |n|) >the loop test is never satisfied, and one gets a font memory >overflow condition (which is only mildly spurious). > >Possible fixes: make |font_params| an array of |integer|, or >|font_index| (maybe: not sure about this), instead of |halfword|. >Alternatively, in section 578 replace > > if n<=0 then cur_val:=fmem_ptr > >by > > if (n<=0) or (n>max_halfword) then cur_val:=fmem_ptr > Hi Chris, 1. I agree this is a bug and (from past experience) I would say you are due for a cheque (a big one). Assuming font_mem_size>max_halfword the program may [ dek -- $327.68 ] attempt to assign a value >max_halfword to font_params[f]. If range checking were on (who is nowadays running TeX with range checking on?) this would give a "high bound violation" or however this is called in a particular systems. Knuth has always classified such as bugs. (I once got a cheque for an even more obscure range checking error.) As to a fix I have convinced myself that defining @!font_params:array[internal_font_number] of font_index; {how many font solves all problems and introduces no new ones. In particular I have verified with a `virgin INITEX' with font_mem_size=32767 that one can say "\fontdimen 32767 \nullfont" with no problems whereas "\fontdimem 32768 \nullfont" leads to an overflow [font_mem... . Hence TeX makes sure that font_params[f] is allways in the range 7..font_mem_size, i.e., a subset of font_index. As to the other possibilities: your alternative > if (n<=0) or (n>max_halfword) then cur_val:=fmem_ptr is not so good since the result is implementation dependent, on some systems you can use \fontdimen n f with some very large n and on other systems (or the same system with different switches) you can't. I think Knuth's policy for such was that an error is not sufficient, only a fatal error is good enough indication. And whoever wants to set \fondimen 32000 f is probably out of his mind anyway. 2. Did you already have a chance to look at the e-TeX files ? regards peter ------- <<< end The TeX program ************************************************************************