bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely

[<emacs@kosowsky.org>]

Ted Zlatanov wrote at about 06:42:36 -0500 on Sunday, November 3, 2013:
 > On Fri, 25 Oct 2013 21:52:24 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
 > 
 > SM> It's a cleaner workaround, but I'd rather we come up with an actual fix.
 > SM> Do you think you can try to make a patch that adds (in files.el) a new
 > SM> function meant to turn an Elisp file name into an OS file name or return
 > SM> nil if the file can't be accessed by OS primitives?  This function would
 > SM> just delegate its work to the file-name-handler if any, and otherwise
 > SM> just return its argument unchanged.
 > 
 > Would any C-facing code, then, need to apply this function before
 > passing a filename to the OS?  Or do you think this function belongs in
 > every package, which is a much bigger list of potential fixes?

Looking through files.el, I noticed that there is a function that
seems to be similar in intent.

The function is called convert-standard-filename. All it really does
currently is replace invalid characters/filenames for
cygwin/windows-nt/ms-dos.

So one potential solution would be to add a hook to the file name
handler at the beginning of this function and then add this function
to the (optional) functions that Magic file handlers could
address. Thus, for example, magic file types like 'cygwin-mount' would
use this hook while magic file types like 'ange-ftp' would
intentionally not have a file handler here since they would presumably
never touch actual local file system files.

There are however 3 problems with this approach:

1. This would require adding a new (lower-level) function to the list
   of functions requiring a magic file handler and it might take some
   time for each maintainer to add the required handler to their Magic
   code.

2. Since some functions already handle conversion using higher order
   primitives like expand-file-name or true-filename (see #3), the
   file name conversion would often be duplicated.

3. Indeed (surprise, surprise), most of the core functions in files.el
   actually use 'expand-file-name' to expand the file name sometime
   before referencing a file. In fact, expand-file-name is called 64
   times and file-truename is called 13 times in the files.el elisp
   code.  (Conversely, convert-standard-filename is only called by the
   functions make-auto-save-file-name and make-backup-file-name-1.)

So, it seems that calling 'expand-file-name' or 'file-truename' far
from being a "hack" is actually the standard way that emacs uses to
generate an OS-accessible file name. In particular, the workhorse
primitives find-file-noselect and find-file-noselect1 both use
'expand-file-name'.

Given that adding 'expand-file-name' seems to be standard usage for
creating OS-accessible file names,  I don't see why we wouldn't
want to use the same paradigm for expanding file names before passing
them off to C-code (like gnutls) that bypasses the standard elisp file
access primitives. Indeed, such usage should be required best practice
precisely to avoid the problems uncovered in gnutls.el.

So, I guess short of rewriting many of the functions in files.el to
consistently pass file names through some lower level OS-conversion
primitive rather than using expand-file-name or file-truename and
short of similarly adding such a lower level primitive to all relevant
Magic file handlers (including avoiding duplicate calls when higher
level primitives like expand-file-name have already been used), I
think that my proposed patch is not only simpler but also more
consistent with the current usage in files.el