bug#25203: 25.1; crash during message, infinite recursion

[Eli Zaretskii <eliz@gnu.org>]

> From: Hin-Tak Leung <hintak.leung@gmail.com>
> Date: Thu, 15 Dec 2016 00:04:53 +0000
> Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
> 
> emacs -Q -batch -l cjk-enc.el -f batch-force-cjk-write-file Big5.tex
> 
> where cjk-enc.el is a slight enhancement of
> "cjk/utils/lisp/emacs/cjk-enc.el" from http://cjk.ffii.org , with
> 
> diff --git a/emacs/cjk-enc.el b/emacs/cjk-enc.el
> index c8e6706..096ade7 100644
> --- a/emacs/cjk-enc.el
> +++ b/emacs/cjk-enc.el
> @@ -881,7 +881,8 @@
>                (setq last-pos (point))
>                (message "Converting: %2d%%"
>                         (/ (* 100 (point)) (point-max)))))
> -
> +        (message "temp-buf is %s..." (buffer-name temp-buf))
> +        (message "work-buf is %s..." (buffer-name work-buf))
>          ;; Advance to the next character and loop.
>          (forward-char 1))
> 
> and Big5.tex is cjk/examples/Big5.tex

AFAICT, cjk-enc.el shoots itself in the foot by invoking 'message'
from the pre-write-conversion function.  This is a very dangerous
thing to do, as the analysis below shows.  In fact, any I/O that might
require encoding should be completely avoided in pre-write-conversion.
It should be a function that does its work silently without any I/O,
because it is invoked in a context of I/O.  If it does need to do I/O,
it absolutely must make sure that I/O will not use the same encoding
for which the pre-write-conversion function was written.

Here's what happens here:

 . cjk-enc defines a coding-system with a pre-write-conversion
   function cjk-encode.

 . batch-force-cjk-write-file eventually calls cjk-write-file, which
   does this:

    (message "Saving %s and %s" bufname newbufname)
    (let ((coding-system-for-write 'cjk-coding))
      (write-region (point-min) (point-max) newbufname))

 . write-region invokes cjk-encode as part of encoding the text in the
   region.

 . cjk-encode calls 'message', due to the above changes.

 . since this is batch mode, 'message' eventually calls
   message_to_stderr, which attempts to encode the text before writing
   it to the terminal.  But since coding-system-for-write is let-bound
   to a non-nil value, message_to_stderr uses that value for encoding
   (as all the encoding functions do), and that results in recursive
   invocation of cjk-encode, which again tries to output a message to
   the terminal, etc. etc., ad nauseam.

The simplest fix for this that requires no changes in Emacs core is
this:

   (let ((coding-system-for-write locale-coding-system))
     (message "temp-buf is %s..." (buffer-name temp-buf))
     (message "work-buf is %s..." (buffer-name work-buf)))

That is, wrap the above 'message' calls in a let-binding of
coding-system-for-write that avoids recursion, and still does TRT wrt
encoding messages to the terminal in batch mode.  After all, this is
(presumably) debugging code, so it can go some extra length to avoid
interfering with the code it's supposed to debug.

If someone is going to argue that Lisp code should never crash Emacs,
then I can see the following alternatives:

  1. Inhibit messages while calling pre-write-conversion.
  2. Signal an error when pre-write-conversion is called recursively.

I think none of these is a good idea, as they disallow perfectly valid
use cases which don't hit this problem.  The 2nd one is also error
prone in its naïve implementation, and too complex IMO in non-naïve
ones.

So my suggestion is to fix your debugging code as indicated above.

Thanks.