[tex-k] Crash (segmentation fault) from endwrite token

[tttex at mailbox.org]

Hi,

If I am not mistaken, only disallowing expansion of \endwrite is not sufficient to avoid all crashes. An \ifx might for example attempt to access the non-existing reference count of the token list of \endwrite while avoid both outer detection and expansion. The following variant of the code still leads to a crash on my machine while avoiding expansion suppression of \endwrite:

\outer\def\someouter{}
\def\weird{\expandafter\weirda\expandafter{\iffalse}\fi}
\def\weirda#1{\ifx}
\immediate\write16{\weird}\someouter

Would it be a solution to change the definition of the `equiv' of \endwrite in module 1369 from `null' to `null_list'  (as is done for frozen_end_template)?

Best,
Tyge

> Karl Berry <karl at freefriends.org> hat am 17.07.2022 02:45 CEST geschrieben:
> 
>  
> Subject: [tex-k] Crash (segmentation fault) from endwrite token
>     This report is from "user202729" on StackExchange 
>     [ ... https://tex.stackexchange.com/questions/609423 ]
> 
> Thanks for passing that on. DRF proposed this fix, to simply disallow
> \noexpand\endwrite, which seems to be the original source of the problem.
> @x [25.369] l.7717 - disallow \noexpand\endwrite
> if t>=cs_token_flag then
> @y
> if (t>=cs_token_flag)and(t<>end_write_token) then
> @z
> 
> I committed it to TL in r63916, and wrote user202729, and posted on
> tex.sx, and added it to newbug.html at
> https://tug.org/texmfbug/newbug.html#B155endwrite. First code bug since
> the tune-up ...
> 
> If any of the other nefarious TeX examples in that tex.sx question seem
> like they might be bugs, let me know? I surmise if there is no crash,
> Knuth's answer would be "you're getting what you deserve", but hard to
> say for sure.
> 
> Thanks,
> Karl