[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: emacs
Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely
Date: Thu, 24 Oct 2013 14:42:08 -0400

Stefan Monnier wrote at about 13:57:13 -0400 on Thursday, October 24, 2013:
 > >    Specifically, gnutls-negotiate uses the Magic File associated
 > >    primitive file-exists-p to test for the existence of a file but
 > >    then passes off the unmodified (and non-existent) Magic File path
 > Good point.  The problem is the use of file-exists-p (which tests if
 > Elisp code can reach this file) instead of another function along the
 > lines of file-accessible-directory-p, which checks whether the file name
 > is reachable to C-level system primitives.

Note that the predicate "file-accessible-directory-p" is also one of
the primitives that Magic File handlers are "required" to
address... so using "file-accessible-directory-p" would create the
same 'true' response for any valid Magic file path unless one were to
prevent Magic file handling by say wrapping the predicate in a 'let'
where file-name-handler-alist is set to nil).

 > "Unmodified" is not a real problem, although we might want to use some
 > function to "canonicalize" the file name so as to increase the chances
 > that the file is reachable to C-level system primitives.
 > >    either (1) by using the Magic File aware primitive expand-file-name
 > expand-file-name is not the right function, even if in some cases it may
 > happen to help.

Why isn't it the right one?
The function name describes it as "Convert filename NAME to absolute,
and *canonicalize* it." (emphasis added)

It seems that any proper Magic File handler should (by definition)
hook into expand-file-name to provide an absolute canonicalized path,
so I would think if the handler is properly written, then it should
work (by definition).

Alternatively, how else would you recommend generally and portably
canonicalizing a Magic file path?

 > > 2. At the C-code level, there is a bug in that passing a
 > >    non-existent/invalid file path may cause the entire Emacs code to
 > >    crash.
 > Right, this is the most serious of the two problems.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]