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

[<emacs@kosowsky.org>]

Ted Zlatanov wrote at about 18:58:12 -0500 on Monday, November 11, 2013:
 > On Mon, 11 Nov 2013 21:00:56 +0100 Achim Gratz <Stromeko@nexgo.de> wrote: 
 > 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.

That is very similar to my use case...
Similarly, I tend to keep my Emacs windows open until I reboot. On the
other hand, I not infrequently need to close all cygwin processes
(including servers) either to upgrade (as AG notes) or to troubleshoot
some cygwin issue since so long as the cygwin.dll is bound to one
process, I can't completely restart the state of cygwin.

PLUS on some computers, I might have emacs only, on others cygwin
only, on others multiple version of cygwin (I used to have both Cygwin
1.5 and 1.7), and on others all combinations.

Since both cygwin and emacs are workhorses for me, I actually prefer
to not have them bound by dependencies whereby one requires the
installation of the other to work... Nor do I want my emacs updates
tied to the cygwin project (for example, I am currently using cygwin
X_64 but many packages have not yet been ported there. I would hate to
have to wait for an important package like Emacs to be ported every
time cygwin issues a new branch)

Indeed in my emacs-loving-centric world, emacs is more fundamental in
some ways than cygwin. If cygwin ceased to exist for windows, I would
still use Emacs on Windows. So, I like the fact that I can make Emacs adapt
to cygwin via a library (cygwin-mount) rather than requiring a
separate cygwin compile. Introducing a forced dependency to make
things work just seems so unemacs-like.

 > 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.

One of the reasons I prefer cygwin-mount to a cygwin-specific build is
that I can see, understand, and potentially modify the treatment of
such pathnames straight in the elisp code rather than having it hidden
in OS-specific C-code. And if I want to change the behavior I can
patch it using standard elisp functions without having to patch the
c-code and recompile.

In my understanding of emacs, as much as possible should be done in
elisp. C-code is best reserved only for direct system interface calls
and/or for calls where interpreted (byte-compiled) elisp just runs too
slow.

 > 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?

Sure... though how broad vs. narrow would you like that thread to be?

Again, in my world, emacs is fundamental -- I use it across
platforms by choice. Cygwin to me is just a tool I use to make Windows
more like Linux... but it's not something I would use by choice nor is
it something I use across platforms.

So, while I am totally supportive of cygwin compiling their own
version of Emacs, I think that Emacs should also maintain a library
for supporting cygwin in its standalone W32 version -- just like Emacs
has modes for supporting just about anything -- just like if I were on
an old mac, I would want Emacs to have modes for supporting the
original mac os file system & hierarchy.




 > 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