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: Null filename ("") is considered to correspond to an existing, readable, and writable file? Date: Tue, 3 Jan 2006 10:51:20 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1136314382 29774 80.91.229.2 (3 Jan 2006 18:53:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2006 18:53:02 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 03 19:52:57 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EtrGt-0003z8-1K for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2006 19:52:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EtrIW-0008O5-Hx for ged-emacs-devel@m.gmane.org; Tue, 03 Jan 2006 13:54:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EtrHc-000854-Iy for emacs-devel@gnu.org; Tue, 03 Jan 2006 13:53:20 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EtrHT-00081y-Cf for emacs-devel@gnu.org; Tue, 03 Jan 2006 13:53:19 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EtrHT-00081v-9i for emacs-devel@gnu.org; Tue, 03 Jan 2006 13:53:11 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EtrIh-0002mC-Ln for emacs-devel@gnu.org; Tue, 03 Jan 2006 13:54:29 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k03IpLew010912 for ; Tue, 3 Jan 2006 11:51:21 -0700 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k03IpLti024578 for ; Tue, 3 Jan 2006 11:51:21 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k03IpKDB024570 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 3 Jan 2006 11:51:20 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:48665 Archived-At: > I already said that I assumed this was "by design". I asked > what the design _advantage_ is. No answer, so far. A file name "" is extrememly rare, so how we behave when facing such a situation should be driven by the two following goals: 1 - avoid risks (e.g. try not to introduce security holes). 2 - try not to spend too much code&time on it. I.e. the behavior should mostly be determined by the way the code makes it work, as long as it makes sense and is not dangerous. See below on "extremely rare". Those general design goals are fine, but they don't speak specifically to the advantage of _this_ particular design. They don't, for example, show an advantage over considering "" to not be a file name (neither relative nor absolute). Is there some security advantage? Does it take less time or code? If you could give us some background as to why you care so much about the way Emacs handles a file named "", maybe you'd be taken more seriously. As I said, I am not interested in trying to _change_ the current behavior. I wanted to _understand_ the rationale for it. I wanted to understand the advantage it provides - I thought perhaps I was missing something. Based on the lack of an answer to my query (so far), I guess there is no advantage and I wasn't missing anything. That's OK; now I know. (If anyone does see an argument for the design, I'm still interested.) My main point in writing about this, which I keep repeating is my main point, is that the _doc_ is not clear enough. As to why I "care so much" and the "extreme rarity" of an empty file name, I've already given this simple example (twice): (while (or (string= "" name) (not (file-readable-p name))) (setq name (read-file-name prompt...))) The example shows: - A program often (not extremely rarely) needs to account for user-input filenames. Whereas "" as a name might be rarely constructed in a program, and is impossible as the name of a real file, user input can require a program to deal with the empty-name case. - The confusion that could (and will) arise from the fact that there is no explanation of the file-name arg for these functions whose names suggest that they act differently than they do. It shows, too, what you must do to deal correctly with the problem. Such an example, by itself, would in fact be enough as doc to dispel possible confusion: it shows that `file-readable-p' by itself does not guarantee that the name names a readable file. I propose: 1) Documenting the file-name arg in each of these functions, mentioning: a) that the name can be either relative (to the `default-directory') or absolute, and b) specifically reminding readers that "" is a relative file name, so, provided `default-directory' is an existing (or readable, or writable) directory, the function will return non-nil for "" 2) More clearly expressing the general definition of a relative file name, specifically pointing out that "" is considered a legitimate relative file name, and that the name is relative because it does not start with / or ~.