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

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 11 Nov 2013 21:00:56 +0100 Achim Gratz <Stromeko@nexgo.de> wrote: 

AG> Ted Zlatanov writes:
>> Could we just call http://cygwin-lite.sourceforge.net/html/cygpath.html
>> on the path (or the equivalent C function)?  It seems to be guaranteed
>> to work but may be very slow with the execution overhead.

AG> Please refer to the official Cygwin documentation, not some unmaintained
AG> project that stopped getting updates over a decade ago:

AG> http://cygwin.com/cygwin-ug-net/using-utils.html

Thanks.  I went with Google, incorrectly.

AG> Specifically for Emacs, the "-m" option to cygpath seems the most
AG> suitable.  Please do not link to the Cygwin DLL from Windows Emacs
AG> (i.e. "using the equivalent C function").  The only reason to use a
AG> native Emacs on Windows (for me anyway) is that I can update Cygwin
AG> while I keep Emacs running and that wouldn't be possible if the DLL was
AG> locked because it was still in use.  For anything else (if you don#t
AG> want to start an X server), there's emacs-w32 from Cygwin.

OK, that sounds like a reasonable use case.

On Mon, 11 Nov 2013 15:00:39 -0500 <emacs@kosowsky.org> wrote: 

> Ted Zlatanov wrote at about 14:42:46 -0500 on Monday, November 11, 2013:
>> Could we just call [cygpath]?

> It would work for cygwin... but I see two limitations:

> 1. The same problem that affects cygwin-mount, would affect any other
>    magic file handler that translates file names, since once again
>    file-exists-p would return true, while the path passed to the
>    c-code would in general not point to an OS-recognizable file.

Yes, right.  There would have to be some logic somewhere in Emacs to
recognize magic Cygwin pathnames and treat them specially from a native
non-Cygwin W32 build.  Then packages like gnutls.el that talk to system
libraries can use that logic.  I don't think it can be accomplished
otherwise.

> 2. The suggestion seems to be far kluggier than my suggested patch
>    since it relies on a user elisp routine passing executing a system
>    call to return a path every time a gnutls connection is
>    requested. At least cygwin-mount does this only once at startup and
>    abstracts the translation away from higher level routines -- which
>    is the entire purpose of a magic file handler.

>    If cygpath belongs anywhere, it would be in the magic file handling
>    code. Though cygwin-mount does this in a "smarter" way by calling
>    'mount' once to determine the cygwin prefix once-and-for-all, and
>    then whenever a path is passed, the magic handler automatically
>    prefixes on the cygwin mount prefix.

> Once again, the problem is not cygwin-mount, per-se. The problem is
> the inconsistency between using the magic file enabled predicate
> file-exists-p to test for a file and then passing that same file name
> to c-code that knows nothing about magic file handlers.

I honestly don't have a preference for cygpath vs. cygwin-mount but
would like to continue the discussion in a new ticket please.  Could we
start a new ticket specifically for the generic problem we've found with
native Emacs W32 builds vs. Cygwin?

I should add here that I'm grateful for all the help and suggestions I
got from you, Eli, and the other participants.  The bug in the GnuTLS
interface code affected potentially all users, not just this one case.

Thanks
Ted