bug#30116: [PATCH] `substitute' crashes when file contains NUL characters (core-updates)

[Ludovic Courtès]

Maxim Cournoyer <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> Maxim Cournoyer <address@hidden> skribis:
>>
>>> In the `patch-el-files' phase of the emacs-build-system, we find the
>>> following snippet:
>>>
>>>     (with-directory-excursion el-dir
>>>       ;; Some old '.el' files (e.g., tex-buf.el in AUCTeX) are still encoded
>>>       ;; with the "ISO-8859-1" locale.
>>>       (unless (false-if-exception (substitute-cmd))
>>>         (with-fluids ((%default-port-encoding "ISO-8859-1"))
>>>           (substitute-cmd))))
>>>
>>> In case an exception is returned while processing the file, it is
>>> retried being opened with the "ISO-8859-1" encoding. Or, this resolves
>>> to a call to `open-file', which documentation says:
>>>
>>> ‘b’
>>>           Use binary mode, ensuring that each byte in the file will be
>>>           read as one Scheme character.
>>>
>>>           To provide this property, the file will be opened with the
>>>           8-bit character encoding "ISO-8859-1", ignoring the default
>>>           port encoding.  *Note Ports::, for more information on port
>>>           encodings.
>>>
>>> So, by opening an file whose encoding is unknown as a ISO-8859-1 file,
>>> we are doing the same as if we had passed the 'binary option. Could this
>>> explain why we end up with NUL characters where we were expecting text?
>>
>> That could be the reason.  Guile provides a way to honor Emacs-style
>> ‘encoding’ declarations, and ‘call-with-input-file’ does that if we pass
>> #:guess-encoding #t (info "(guile) Character Encoding of Source Files").
>>
>> Did the faulty file have such a declaration?
>
> Sadly, it doesn't. Although even if it did, I don't think it would be
> very robust to expect every misbehaving files we might encounter to
> include one!

Sure, I was asking just because it’s an Emacs-related package.

> So I think we should apply my v2 patch to core-updates for now (see my
> previous reply on this thread), until we have our substitute routine
> implemented using srfi-115!

Sounds good!  Note that I’ll wait until after the current ‘core-updates’
has been merged.  Please do ping me if you think I’ve forgotten!

Thanks,
Ludo’.