summaryrefslogtreecommitdiff
path: root/info/digests/tex-implementors/message.44
blob: c2defa8449395db5f1e2a2aa7b522b2fd63ee46b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
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

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