bug#36573: 26.1; bufferpos-to-filepos assumes coding-system-eol-type gives integer

[Eli Zaretskii <eliz@gnu.org>]

> From: Rupert Swarbrick <rswarbrick@gmail.com>
> Date: Wed, 10 Jul 2019 11:52:24 +0100
> 
> The bufferpos-to-filepos function assumes that the return value fo
> coding-system-eol-type is an integer, testing it with
> 
>   (let* ((eol (coding-system-eol-type coding-system))
>          (lineno (if (= eol 1) (1- (line-number-at-pos position)) 
>          0))
>          ...)
>     ...)
> 
> However, coding-system-eol-type may return a list if the given 
> coding system doesn't specify eol conversion explicitly.

That shouldn't happen for a buffer that visits a file, in general.

> This crops up for me when trying to browse info files:
> 
>   Debugger entered--Lisp error: (wrong-type-argument 
>   number-or-marker-p [undecided-unix undecided-dos undecided-mac])
>     =([undecided-unix undecided-dos undecided-mac] 1)
>     (if (= eol 1) (1- (line-number-at-pos position)) 0)
>     (let* /* SNIP contents of bufferpos-to-filepos */)
>     bufferpos-to-filepos(1202 exact)
>     Info-read-subfile(1200)
>     Info-find-node-2("/usr/share/info/gawk" "Top" nil nil)
>     Info-find-node("gawk" "Top" nil nil)
>     Info-goto-node("(gawk)" nil)
>     Info-menu("Gawk" nil)
>     funcall-interactively(Info-menu "Gawk" nil)
>     call-interactively(Info-menu nil nil)
>     command-execute(Info-menu)

Please show the entire recipe for reproducing this, starting from
"emacs -Q".  Info files should generally have the -unix EOL type;
that's what I see here.  So I wonder how did we get into this
situation.

> (I've snipped out the contents of bufferpos-to-filepos from the
> backtrace). It seems that the coding system for the info file is
> 'undecided at this point.

On my system, "C-u C-h i /path/to/gawk.info RET" yields a buffer whose
buffer-file-coding-system is undecided-unix, as I'd expect.  This
happens both on GNU/Linux and on MS-Windows.  So I wonder how you get
something different.  One can get undecided with empty buffers, or
buffers that don't have a single newline, but this is not that case.

> I'm not sure where the bug lies. If bufferpos-to-filepos (and
> filepos-to-bufferpos) are supposed to work with an undecided 
> coding system, they need fixing.

This function cannot possibly work with an encoding that has no
definite EOL type, because obviously the conversion of buffer
positions to file offsets depends on that.

> Manually replacing "(= eol ...)" with "(eql eol ...)" locally in
> both functions means that I can read the info file again (yippee!)
> but I'm not sure whether that's a full solution.

It could be, but we should first understand how did that happen,
because there might be deeper problems hiding here.

> Alternatively, I guess the documentation for these functions needs
> to say that they should only be called when the coding system
> specifies eol conversion.

That should be done regardless, I think.  But since this function was
written specifically for Info files, it must work there (and did,
AFAIK, since the day it was written till now).