bug#81445: 30.2; Crash with Nonspacing Mark

> From: Stefan Monnier <[email protected]>
> Cc: [email protected],  [email protected]
> Date: Sun, 26 Jul 2026 16:13:27 -0400
> 
> > Stefan, would you mind reviewing the patch and commenting, before I
> > install it?  These are somewhat tricky matters, so I'd like another
> > pair of eyes.  The context is that binding auto-coding-regexp-alist
> > overrides the 'coding:' cookies, and the uni-*.el files _must_ be read
> > using utf-8-emacs-unix, come hell or high water, or else Emacs can
> > crash.
> 
> See my questions below:
> 
> > @@ -1271,7 +1272,19 @@ uniprop_table (Lisp_Object prop)
> >    if (STRINGP (table))
> >      {
> >        AUTO_STRING (intl, "international/");
> > +      /* The uni-*.el files _must_ be read using utf-8-emacs-unix, or
> > +         else Emacs might crash.  We bind coding-system-for-read below
> > +         to protect against some Lisp which overrides the coding:
> > +         cookies in the uni-*.el files by, for example, binding
> > +         auto-coding-regexp-alist to some strange value.  */
> > +      specpdl_ref count = SPECPDL_INDEX ();
> > +      if (NILP (Vcoding_system_for_read))
> > +	{
> > +	  Lisp_Object coding = coding_inherit_eol_type (Qutf_8_emacs, Qunix);
> > +	  specbind (Qcoding_system_for_read, coding);
> > +	}
> >        result = save_match_data_load (concat2 (intl, table), Qt, Qt, Qt, Qt);
> > +      unbind_to (count, Qnil);
> >        if (NILP (result))
> >  	return Qnil;
> >        table = XCDR (val);
> > @@ -1376,4 +1389,5 @@ syms_of_chartab (void)
> >  	       doc: /* Alist of character property name vs char-table containing property values.
> >  Internal use only.  */);
> >    Vchar_code_property_alist = Qnil;
> > +  DEFSYM (Qcoding_system_for_read, "coding-system-for-read");
> >  }
> 
> This looks acceptable, but:
> 
> - Why test NILP (Vcoding_system_for_read)?

Because if the caller (or user) has already bound
coding-system-for-read, that binding may not be overridden.  This is
the usual protocol of using these variables, since they are global.

> - IIUC the problem shows up after bootstrap, so AFAIK we should be
>   loading a `.elc` file here, and AFAIK we always load `.elc` files
>   with utf-8 (or the old `emacs-mule` if we detect an ancient file, but that
>   should never occur here).
>   So I don't understand why that would be confused by a weird setting
>   of `auto-coding-regexp-alist`.
> 
> Oh, wait, I guess it's because some of those files have
> `no-byte-compile:t`.

Yes, all of them.

> So maybe a better option is to specbind
> `Vload_source_file_function` to nil so we'd also avoid the overhead
> of going through `load-with-code-conversion` for those files, where's
> it's just a waste, AFAICT, and has a non-negligible performance impact.
> 
> [ I'm also favorable to removing the `no-byte-compile:t` from those
>   files unless the corresponding `.elc` is really worse.  ]

I feel that the change I suggest above is more conservative and local,
thus safer.  After all, this code has been working for us since at
least Emacs 25, with no problems, until this semi-crazy use case cam
along.