path: root/info/digests/tex-implementors/message.44

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 <CET1@phx.cam.ac.uk>
To: Barbara Beeton <BNB@MATH.AMS.COM>
Cc: Robert Hunt <REH10@phx.cam.ac.uk>
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 <CET1@phx.cam.ac.uk>
To: Barbara Beeton <BNB@MATH.AMS.COM>
Cc: Robert Hunt <REH10@phx.cam.ac.uk>
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 <CET1@phx.cam.ac.uk>
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
> \<numeric> |<| \<numeric> 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 <A8131DAL@AWIUNI11.EDVZ.UniVie.AC.AT>
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 <CET1@phx.cam.ac.uk>
To: Peter Schmitt <A8131DAL@AWIUNI11.EDVZ.UNIVIE.AC.AT>
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" <Denis.Roegel@loria.fr>
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" <Denis.Roegel@loria.fr>
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 <CET1@phx.cam.ac.uk>
To: Rainer Schoepf <Schoepf@sc.ZIB-Berlin.DE>
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 <CET1@phx.cam.ac.uk>
Cc: Barbara Beeton <BNB@MATH.AMS.ORG>, Rainer Schoepf <Schoepf@sc.ZIB-Berlin.DE>
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
]

  <Nullify |width(q)| and the tabskip glue following this column@>

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 <CET1@phx.cam.ac.uk>
To: Rainer Schoepf <Schoepf@sc.ZIB-Berlin.DE>
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
>
>   <Nullify |width(q)| and the tabskip glue following this column@>
>
> 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}
@y
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 <CET1@phx.cam.ac.uk>
To: Barbara Beeton <BNB@MATH.AMS.ORG>
Cc: Andrew Trevorrow <andrew.trevorrow@anu.edu.au>
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 <BNB@MATH.AMS.ORG>
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 <BNB@MATH.AMS.ORG>
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 <BNB@MATH.AMS.ORG>
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 <BNB@MATH.AMS.ORG>
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 <PEB%DMUMPIWH.BITNET@vm.gmd.de>
To: bbeeton <BNB@MATH.AMS.ORG>
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]<non_address
   and changing non_address from very large too very small requires a change
   here too (I'll check if there are more places)
3. I dislike the change of   font_index=0..font_mem_size  into
   font_index=-1..font_mem_size  because on some systems that may have
   the effect that 4 bytes instead 2 bytes are required for a font_index
4. I think one can safely set  non_address=0  but I have to check that
   and will send you a complete fix tomorrow.
5. I will also reformulate my  "bug or design feature" msg from some
   time ago and would like to ask you to forward it to don.
regards Peter
-------
(reply, 09 Mar 1994)
thanks much, peter.
[ forwarded all previous mail to peter ]
-------
Date: 09 Mar 1994 11:51:32 -0800 (PST)
From: drf@frame.com (David Fuchs)
Subject: Re:  [andrew.trevorrow@anu.edu.au (Andrew K Trevorrow): new TeX bug]

I'd forward it along to dek; [...]

 -drf
-------
(reply, 09 Mar 1994)
what's becoming clear about this particular bug is that it impinges
on some of the system-dependent areas, in particular, how various
implementors choose to implement the ability to change the size of
various memory blocks at run time.  since more implementations do
have that ability now than formerly, and they all seem to be
implemented differently (though not all techniques are public),
this is potentially a rats nest.  so information is important not
only on what the bug is and how you can make it happen, but what
else is related and where it might go wrong if fix x is adopted.
i think the present participants are capable of doing a pretty
thorough job.
-------
Date: 10 Mar 1994 11:27:26 +0000 (GMT)
From: Peter Breitenlohner <PEB%DMUMPIWH.BITNET@vm.gmd.de>
To: Barbara Beeton <bnb@MATH.AMS.ORG>,
 Chris Thompson <cet1@phoenix.cambridge.ac.uk>,
 Andrew Trevorrow <andrew.trevorrow@anu.edu.au>,
 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_addres  must be changed into  ...>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}
@y
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_min<mem_bot-2 then mem[mem_min]
is also never used (done in undump memory). Hence the word mem[mem_min]
is either a glue spec or unused. This can never give a problem
with tests such as    p>mem_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 <CET1@phx.cam.ac.uk>
To: Barbara Beeton <BNB@MATH.AMS.ORG>
Cc: Andrew Trevorrow <andrew.trevorrow@anu.edu.au>,
 Peter Breitenlohner <PEB@DMUMPIWH.EARN>,
 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<amazingly large number>? 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 <PEB%DMUMPIWH.BITNET@vm.gmd.de>
To: Berthold Horn <71172.524@CompuServe.COM>
Cc: Barbara Beeton <bnb@MATH.AMS.ORG>,
 Chris Thompson <cet1@phoenix.cambridge.ac.uk>
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_min<min_halfword=null and
[ dek - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	 Absolutely true  (see \S116)
]
2. should never use mem[mem_min] (whatever the present mem_min value) unless
   your proposed code change is made
3. never ever use mem[min_halfword].
I agree a change in mod 174 ( p>mem_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 <PEB%DMUMPIWH.BITNET@vm.gmd.de>
To: Andrew K Trevorrow <andrew.trevorrow@anu.edu.au>,
 Barbara Beeton <bnb@MATH.AMS.ORG>
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 <CET1@phx.cam.ac.uk>
To: Barbara Beeton <BNB@MATH.AMS.ORG>
Cc: Andrew Trevorrow <andrew.trevorrow@anu.edu.au>,
 Peter Breitenlohner <PEB@DMUMPIWH.EARN>,
 Berthold Horn <71172.524@CompuServe.COM>
Subject: Small TeX bug - \fontdimen <large-number>

Barbara,

I wrote:
> (There is curiosity, though: |font_params| is an array of |halfword|s.
> Can one break TeX by setting \fontdimen<amazingly large number>? 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 <PEB%DMUMPIWH.BITNET@vm.gmd.de>
To: Chris Thompson <CET1@PHOENIX.CAMBRIDGE.AC.UK>
Subject: Re: Small TeX bug - \fontdimen <large-number>

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<amazingly large number>? 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

************************************************************************