From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: file-truename, convert-standard-filename Date: Sun, 7 Feb 2010 18:46:41 -0800 Message-ID: References: <83k4urfqs9.fsf@gnu.org><0B5BFE3DC87648888328B75164292F06@us.oracle.com><83bpg2g2l8.fsf@gnu.org><834oluf9c8.fsf@gnu.org><07544B532C8E490F96FE0B1CF403C510@us.oracle.com><83zl3mdo22.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1265597299 17556 80.91.229.12 (8 Feb 2010 02:48:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Feb 2010 02:48:19 +0000 (UTC) Cc: 'Eli Zaretskii' , emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 08 03:48:16 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NeJfb-0001L2-50 for ged-emacs-devel@m.gmane.org; Mon, 08 Feb 2010 03:48:15 +0100 Original-Received: from localhost ([127.0.0.1]:37771 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NeJfZ-0006Kk-Pp for ged-emacs-devel@m.gmane.org; Sun, 07 Feb 2010 21:48:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NeJfU-0006Jy-2i for emacs-devel@gnu.org; Sun, 07 Feb 2010 21:48:08 -0500 Original-Received: from [199.232.76.173] (port=40878 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NeJfT-0006Jn-HW for emacs-devel@gnu.org; Sun, 07 Feb 2010 21:48:07 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NeJfR-0001H3-Iu for emacs-devel@gnu.org; Sun, 07 Feb 2010 21:48:07 -0500 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]:31467) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NeJfQ-0001Fy-GN; Sun, 07 Feb 2010 21:48:04 -0500 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o182lxJx025922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Feb 2010 02:48:00 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o1818MkM013095; Mon, 8 Feb 2010 02:47:58 GMT Original-Received: from abhmt014.oracle.com by acsmt355.oracle.com with ESMTP id 16636091265597193; Sun, 07 Feb 2010 18:46:33 -0800 Original-Received: from dradamslap1 (/24.5.185.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 07 Feb 2010 18:46:33 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcqoX2Jq/78srU1zRHuvJfowAHP7JQAAHQJw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4B6F7B5F.004E:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:121018 Archived-At: > > THEORETICALLY, one _always_ needs c-s-f, unless either (1) you know > > that the file that is named exists or (2) you know _all_ of the > > following: (2a) the file system being used, (2b) the file name being > > used, and (2c) that the given file name is a valid one for the given > > file system. > > No, I think it should be more restrictive: you should use c-s-f if and > only if the file name might not be valid on the current system, and > where it would be a bug if that file name turned out to be invalid on > the current system. >From that and the rest of what you wrote, you seem to be speaking of a usage guideline that is more restrictive based on PRACTICAL considerations. The text you quoted was, in contrast, trying just to describe the cases that THEORETICALLY could be problematic. It says nothing about practical guidelines: what to do about such cases (avoid them by using c-s-f or not). I was trying to paraphrase what Eli said when he was describing which cases could be problematic. Those are (I think) the criteria he cited. They are presumably the rationale behind the current use of c-s-f (e.g. in defcustoms). But he also said that in practice such cases are marginal (rare). And you've now added that even for some of those rare cases we don't care enough to protect against an error. It is a PRACTICAL matter whether the problematic cases are in fact rare (they are, apparently). And it is a PRACTICAL matter whether some of the problematic cases should be ignored (so that an error is raised) if they arise. If the code doesn't know what the current system might be when it is run, then c-s-f is needed IF you want to be sure there is no problem. The "IF" part is a PRACTICAL choice. (Of course, if the set of problematic OSes is known, then the code can test to see whether the current OS is one of them - but I didn't notice such a test in the current Emacs code.) > In most cases, the first condition is already false: you generally get > file names which you know are valid on the current system. "Generally" as in most often? Sure. "Generally" as in you can depend on that to be the case? No. Again, that's the point I was trying to make in distinguishing theoretical from practical considerations. If you don't know, then THEORETICALLY you need to call c-s-f, that is, IF you want to play safe. IN PRACTICE, however, you might not care. I'm just paraphrasing what I understood from Eli. I don't claim either that I understood him correctly or that what he said is right. ;-) > Of the remining cases, most fail the second condition: for most > files that may not be valid, it's perfectly OK to signal an > error if it turns out to be invalid, because it was a > user-error to use that file name. That's a legitimate point - and it's a design choice, i.e., a PRACTICAL matter. By "THEORETICALLY", I was trying to describe the situations in which you wouldn't know enough to determine whether the file name might be invalid - and so c-s-f would be called for IF you wanted to play it safe. If instead it makes sense to let an error be raised because of an invalid name, that's a different story. That choice doesn't affect the criteria that define a problematic case. Making such a choice is a PRACTICAL matter. Eli was trying to help me understand both (a) the potential problem and (b) when and whether it arises in practice. I had trouble understanding, because there is a difference between the two. He seemed at first to be saying contradictory things (you need c-s-f to protect against... vs you probably don't need c-s-f). > So yes, the cases where c-s-f are needed are rare and mostly > "internal". Got it. I won't need c-s-f at all. I was confused because I ran across it in the doc, and from its description it seemed to be something I would need in order to compare file names. I suggest that we remove it from the manual and clarify the doc string, so that users who run across it don't use it unnecessarily. > > IN PRACTICE, however, the only real use-case is for > > MS-DOS support, and in particular, only when the file > > name is a literal string in Lisp code.