From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20634 invoked by alias); 5 Apr 2006 22:00:29 -0000 Received: (qmail 20625 invoked by uid 22791); 5 Apr 2006 22:00:29 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Apr 2006 22:00:28 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k35M0Q4i023869 for ; Wed, 5 Apr 2006 18:00:26 -0400 Received: from opsy.redhat.com (vpn50-152.rdu.redhat.com [172.16.50.152]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k35M0KFw017433; Wed, 5 Apr 2006 18:00:21 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 9EA3E2DDE69; Wed, 5 Apr 2006 15:53:39 -0600 (MDT) To: Gary Benson Cc: java-patches@gcc.gnu.org Subject: Re: Patch: rewrite File.toCanonicalPath() for GNU/Posix systems References: <20060403123246.GA5292@redhat.com> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Wed, 05 Apr 2006 22:00:00 -0000 In-Reply-To: <20060403123246.GA5292@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2006-q2/txt/msg00038.txt.bz2 >>>>> "Gary" == Gary Benson writes: Gary> The diff of the method itself is not particularly legible, so I've Gary> attached a copy of the new method as well. This is looking good. I had a couple of questions though. First: - // Special case: treat "" the same as ".". - if (total == 0) - buf[total++] = '.'; Is this now handled some other way? I didn't try to trace through the logic. I forget if there is a test for this... if not there ought to be. Gary> // Unlike other JVMs we do not rewind past the root Gary> // directory. I can't see any legitimate reason why you Gary> // would want this, and chopping off bits of path seems Gary> // like a sure-fire way to introduce vulnerabilities. I'm curious about this. It seems a bit weird that it would be valid to try to open "../../../foo" but not to get the canonical path name of that same file. Tom