Not a bug in original TeX

This page lists a few reports which could plausibly look like significant bugs in the original (Knuthian) TeX distribution, but have been deemed not a bug by Knuth or his vetters. Many other reports have been declined that are not listed here (Knuth's tune-up reports mention some: 2014, 2008). The original reports and answers have been edited or paraphrased for presentation here.

The page and module numbers are just an initial hint about a relevant location; typically more than one place in the code is involved. The initial letter (A, B, …) refers to the Computers & Typesetting volume.

A list of reported bugs for the next tune-up is also available. These are not expected to be reviewed by Knuth until the next tune-up.

For any discussion about these issues, or further reports, please use the contact information on the main TeX bugs page here.

Contents: \ninebig delimiters - input file name flushed - line number ranges - bogus dimen display - output routine braces - unused variable declared.


A415: \ninebig delimiters axis height

From Hu Yajie 胡亚捷: 2020-07-29 and 2020-07-29 again and 2020-08-02.

The \ninebig macro in manmac.tex typesets \big delimiters in 9-point math by borrowing the 10-point ones in cmr10 and cmsy10, but it forgets to retain the 9-point axis height. Thus examples like \input manmac \ninepoint $\bigl(()\bigr)$\end are vertically asymmetrical. This asymmetry can be observed in the real books (page A245, line 20; page C298, line -1; etc.), and it can be fixed by changing ‘\hbox{...}’ to ‘\vcenter{\hbox{...}}’ to get vertical symmetry.

Knuth accepts the analysis, but says: “Since I've been happy with that for nearly 40 years, I guess I'm still happy with it.”


B214 (module 537): input file name flushed prematurely

From Wolfgang Helbig, 2020-10-26:

TeX sometimes flushes the name of an input file, keeping only the base name without directory and extension. This causes an error if the full name of the file needs to be passed to the editor during error recovery, as suggested by Prof. Knuth. The same bug is in Metafont (module 793).

[...] change block[s] from my tex.ch [...]:

@x [tex 537] continued
if name=str_ptr-1 then {we can conserve string pool space now}
   begin flush_string; name:=cur_name;
   end;
@y
@^Editor@>
@z

Response: the assumption was that on any “reasonable” OS, you could easily ask the system for the full canonical file name of the appropriate open alpha_file when you need it, so there's no need for TeX to remember it. Since *nix is not able to do this in general, dealing with this in the changefile as shown seems reasonable. (There are various system-dependent ways to approximate this, but no reliable and portable method is possible.)

On the other hand, filesystems on popular TeX-able OSes of the day (TOPS-20, VAX/VMS, etc.) had both Logical Name and Version Number features, resulting in the need to ask the OS for the full name of the file that actually got opened.

This call to flush_string also causes a non-standard filename extension to be lost when calling the editor. Knuth recommends that implementors avoid this, either via Wolfgang's change that eliminate flushing the string or some other method.

These issues all fall under the rubric of “system wizardry” mentioned in the description of the E option (page B036, module 84).


B274 (module 663): line number ranges may come from different files

From Udo Wermuth, 2017-01-25.

In overfull/underfull box messages, the beginning and ending lines shown might come from different files, and thus be misleading. Suppose we have a file main.tex containing this line:

Main 1\par \input auxone \end

and a file auxone.tex with these two lines:

Aux1 1\par
Aux1 2 bug in underfull message?\break

then running tex main gives:

This is TeX...
(./main.tex (./auxone.tex)
Underfull \hbox (badness 10000) in paragraph at lines 2--1
...

A range of lines that begins after it ends does not make sense. Also, a user will connect both numbers to the file main.tex as it is the only active file; there is a ) after auxone.tex, so this file has been processed.

The situation can also occur in alignments and with overfull messages. It is shown in the trip test.

Response: Indeed, and because it is shown in the trip test, we can conclude that DEK was aware that if you started a paragraph in one source file and ended it in another, then line numbers in messages would be problematic. The attitude was that robustness in the face of this edge case (not a recommended best practice) wasn't worth the extra bytes of memory (both code and data). Especially since the rest of the context is usually clear from the logging of the actual text of the paragraph.


B506 (module 1238): bogus display of bogus dimen

From Bruno Le Floch, 2020-10-22.

Slightly incorrect display of 32768pt dimen: The following shows --32768.0pt with a double minus sign.

\dimen0=\maxdimen
\advance\dimen0\maxdimen
\advance\dimen0 2sp
\showthe\dimen0

Response: any bug is the lack of an error message at \advance\dimen0\maxdimen, but the lack of overflow checking is pervasive in TeX, and is a deliberate choice by Knuth. The resulting display is a case of GIGO.


B546 (module 1372): output routine braces are super special

From Bruno Le Floch, 2020-10-22.

The \output routine is surrounded by very peculiar braces, and by removing the closing one with \let\next=, one ends up in a black hole where TeX does not interpret any further token. My question and answer on tex.sx describe the strange behaviour. It is probably not a bug as there is an explicit comment “loops forever if reading from a file”. It would be interesting to have a rationale.

Response: The idea here is that “The error message [I can't handle that very well] told you you've made a mess, and if the error message isn't enough, then the help info warns you that error recovery is not likely, and if that's not enough, then you'd better look at Volume B.” Basically, “I can't handle that very well” includes the possibility “I can get in a loop.”

As for a rationale, it would be more or less impossible to generally recover into any sensible state, and certainly not one that would give any reasonable subsequent output. This is a case that normal users of macro packages and documents would never run into, and would need a deep expert's close study to fix, so it is not worth spending time or (precious, at the time) bytes of code on trying to let the job continue, most likely fruitlessly in the end.

For that matter, it's somewhat surprising that this case doesn't just bail out immediately, as with the few

fatal_error("(interwoven alignment preambles are not allowed)")

cases, or the favorite:

confusion("256 spans"); {this can happen, but won't}
both of which are more likely for a real user to run into directly.

D350 (module 788): unused variable m declared

From David Fuchs, 2021-01-24.

This line in mf.web should be removed:

@!m:integer; {the current month}

as the local variable k is used, as correctly commented, by open_log_file for indexing into months, and m is now an unused variable.

Response from DEK: In accordance with the wonderful Japanese tradition of wabi-sabi, I won't be changing that.


For any discussion about these issues, or further reports to be listed here, please use the contact information on the main TeX bugs page here.


$Date: 2021/02/07 22:33:25 $;
TUG home page; webmaster; facebook; twitter;   (via DuckDuckGo)