From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.bugs Subject: bug#15648: 24.2.50; gnutls SSL connection to IMAP server causes emacs to crash completely Date: Sun, 03 Nov 2013 10:12:27 -0500 Message-ID: <21110.26587.721061.28128@consult.pretender> References: <21089.32240.198931.971000@consult.pretender> <21096.1667.116936.254737@consult.pretender> <83eh7bj1yq.fsf@gnu.org> <87ppqvke5u.fsf@flea.lifelogs.com> <87fvrun1pw.fsf@flea.lifelogs.com> <21093.32992.278229.646703@consult.pretender> <877gd5mo5x.fsf@flea.lifelogs.com> <21094.39055.449629.706850@consult.pretender> <21094.40085.664080.69561@consult.pretender> <21094.52645.645440.977584@consult.pretender> <21094.64459.131668.849138@consult.pretender> <21095.19949.639350.970770@consult.pretender> <21096.24492.292723.589004@consult.pretender> <87eh7bj5no.fsf_-_@flea.lifelogs.com> <21097.10816.221279.461499@consult.pretender> <21097.27136.910137.181740@consult.pretender> <21098.31018.184128.497305@consult.pretender> <87y555socz.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1383491659 14687 80.91.229.3 (3 Nov 2013 15:14:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Nov 2013 15:14:19 +0000 (UTC) Cc: emacs@kosowsky.org, 15648@debbugs.gnu.org To: Ted Zlatanov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 03 16:14:22 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VczNa-0006oI-S3 for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Nov 2013 16:14:19 +0100 Original-Received: from localhost ([::1]:45473 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VczNa-0007xb-Da for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Nov 2013 10:14:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46065) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VczNR-0007xN-4V for bug-gnu-emacs@gnu.org; Sun, 03 Nov 2013 10:14:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VczNK-0005ZV-E6 for bug-gnu-emacs@gnu.org; Sun, 03 Nov 2013 10:14:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47005) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VczNK-0005ZO-A2 for bug-gnu-emacs@gnu.org; Sun, 03 Nov 2013 10:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VczNJ-0000zA-RC for bug-gnu-emacs@gnu.org; Sun, 03 Nov 2013 10:14:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Nov 2013 15:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15648 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15648-submit@debbugs.gnu.org id=B15648.13834915933724 (code B ref 15648); Sun, 03 Nov 2013 15:14:01 +0000 Original-Received: (at 15648) by debbugs.gnu.org; 3 Nov 2013 15:13:13 +0000 Original-Received: from localhost ([127.0.0.1]:32791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VczMW-0000xz-F5 for submit@debbugs.gnu.org; Sun, 03 Nov 2013 10:13:12 -0500 Original-Received: from vms173007pub.verizon.net ([206.46.173.7]:53109) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VczMT-0000xl-Kc for 15648@debbugs.gnu.org; Sun, 03 Nov 2013 10:13:10 -0500 Original-Received: from consult.pretender ([unknown] [72.93.211.153]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MVP00MCN0WSXY60@vms173007.mailsrvcs.net> for 15648@debbugs.gnu.org; Sun, 03 Nov 2013 09:12:40 -0600 (CST) Original-Received: from consult.pretender (consult.pretender [127.0.0.1]) by consult.pretender (8.14.4/8.14.4) with ESMTP id rA3FCRgr029763; Sun, 03 Nov 2013 10:12:28 -0500 In-reply-to: <87y555socz.fsf@flea.lifelogs.com> X-Mailer: VM 8.2.0b under 23.1.1 (i386-redhat-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:79918 Archived-At: 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 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