Apparent bug in pdftex/xetex (but not luatex)

[Marcel Fabian Krüger]

On Tue, Apr 27, 2021 at 04:26:21PM -0600, Karl Berry wrote:
> Hi Marcel - thanks for the patch.
> 
>     +     name_field=18..19 means \scantokens pseudo files
> 
> I can't research right now, seems like that implies that in original TeX
> (where there is no \scantokens), it should start at 18? I wrote that new
> bit of code originally in response to the prior bug reports about
> (original) TeX crashing with "e".

Technically yes, but it doesn't matter. It would only make a difference
if a file would have a filename with string number 18 or 19, but the
first 256 strings are statically initialized for internal purposes
and never used for file names. (E.g. the strings in question are "^^R" and
"^^S", representing the characters 18 and 19) TeX is already depending
on these strings not being reused. (E.g. The strings before 18 exist
too, using small name_field values only works since TeX knows that
the value will always be higher than 256 (actually it will always be
above 1000ish since TeX also sets other internal strings)

So we could make separate cases here, but I don't see the point in
doing so.

> 
>     +#elif defined(MF)
>     +    if (inputstack[is_ptr].namefield <= 2) {
> 
> Good.
> 
>     +#else
>     +#error "Unable to identify program"
>     +#endif
> 
> MetaPost ... --thanks, karl.

MetaPost doesn't use the code, it has a separate implementation in
mpost.web (mpost_run_editor). It doesn't even link in this file. (Which
implies that the filename texmfmp.c is at least misleading, but that's
an independent issue)
That was also the motivation in explicitly testing for MetaFont instead
of just using an else case: We can be sure that we don't accidentially
use wrong values for some other program using the file since it will
fail at compile time if the current program isn't handled.

Best,
Marcel