Subject: bug#75520: Circular code or data can hang Emacs unquittably

From: Eli Zaretskii <[email-masked]>
Date: Tue, 14 Jan 2025 23:13:27 +0200

> Date: Tue, 14 Jan 2025 18:45:51 +0000
> From: Pip Cet <[email-masked]>
> Cc: Paul Eggert <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
> 
> > Seems like we have a consensus here that this should be fixed.
> 
> I agree, but it's a significant task: My git grep caught ~8 bugs, but
> covered only 22% of cases (at best), so I'd naively expect at least 20
> bugs, and fixing them is usually simple but occasionally tedious
> (because one might forget to include an additional check, for example,
> as I did when I accidentally removed a STRINGP (XCAR (tem)) on
> scratch/igc).

We can fix only the most painful ones.  We don't need to make sure
none remain, if it isn't easy.

> > But can we please have at least one test for every place where we fix
> > this kind of bug?
> 
> Assuming you mean a test case that reliably infloops unfixed Emacs:
> probably not.  If the requirement is simply to make some variable
> circular and call code which might refer to it, on the off chance that
> that code would infloop once in a while, maybe.
> 
> And what if we can't find such a test?  I'm pretty sure
> find_font_encoding isn't unused, and it will infloop if
> Vfont_encoding_alist is circular and we don't want to return one of its
> elements, but how do I trigger it?  Even if I managed to trigger it on
> my system (no luck so far), would that do anything on Windows, with its
> totally different font handling code?  Wouldn't it depend on which fonts
> are installed?

I thought concocting tests for this would be easy.  If it isn't, we
don't have to have such tests.

(And Vfont_encoding_alist works on Windows like it works elsewhere.
Everything in font.c is platform-independent, with a small number of
exceptions explicitly marked by #ifdef's.)

Thanks.