From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1637 invoked by alias); 19 Jun 2008 18:58:16 -0000 Received: (qmail 1625 invoked by uid 22791); 19 Jun 2008 18:58:15 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout2.012.net.il (HELO mtaout2.012.net.il) (84.95.2.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 19 Jun 2008 18:57:36 +0000 Received: from HOME-C4E4A596F7 ([84.229.217.57]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K2Q004F55D5DYH2@i_mtaout2.012.net.il> for gdb-patches@sources.redhat.com; Thu, 19 Jun 2008 22:12:42 +0300 (IDT) Date: Fri, 20 Jun 2008 02:49:00 -0000 From: Eli Zaretskii Subject: Re: Better realpath In-reply-to: <200806191006.43356.vladimir@codesourcery.com> X-012-Sender: halo1@inter.net.il To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Reply-to: Eli Zaretskii Message-id: References: <200806141024.41812.vladimir@codesourcery.com> <200806181133.11578.vladimir@codesourcery.com> <200806191006.43356.vladimir@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00356.txt.bz2 > From: Vladimir Prus > Date: Thu, 19 Jun 2008 10:06:42 +0400 > Cc: gdb-patches@sources.redhat.com > > > I don't think such radical measures would be necessary. We could > > either (a) use canonicalize_filename, which doesn't check for > > existence, > > Hmm, the documentation at > > http://www.gnu.org/software/libc/manual/html_mono/libc.html > > say: > > Function: char * canonicalize_file_name (const char *name) > > If any of the path components is missing the function returns a NULL pointer. My version of libc.info says something different: In any of the path components except the last one is missing the function returns a NULL pointer. The "except the last" part makes all the difference. I guess we need to try this to see which one is true. > > or (2) use realpath on the argument's leading directories > > (i.e. call `dirname' to remove the last portion of the file name). Am > > I missing something? > > And this will check dirname existance? This semantics is mid-way between checking > everything for existance, and not checking anything. Is this really intuitive and > desirable? I was aiming for consistency with canonicalize_file_name, assuming it behaves like my reference above says. > > > Second is down-casing. If we don't want brute down-casing, and we want truly canonic > > > names of paths, then "C:/documents and settings" should become "C:/Documents and Settings", > > > and that requires actually poking at the file system to see what exact spelling is stored. > > > > No, that's not necessary either. All you need is run the result of > > GetFullPathName through GetLongPathName: if it fails, it means the > > file does not exist, and you need to return it in whatever letter-case > > it was passed to us; if it succeeds, it will return the file name as > > it's recorded in the filesystem. > > That does not contradict what I say -- it *does* require poking at the file system, Well, _any_ file-related system call eventually pokes the file system. What I meant is that we don't need to do that yourself in application code. > ... what will be the return value of GetLongPathName on "C:/DOCUME~1/nonexistent/nonexistent2" > and "C:/documents and settings/nonexistent/nonexistent2". Presumably, GetLongPathName will > fail in both cases, and GDB will think those paths are unequal. That's true, but it's no worse than today: FILENAME_CMP does not handle comparison of short 8+3 aliases with their long variants. So we don't need to do this if we don't want to. If we do want to handle these cases, I guess we could iteratively chop directories from the right and run them through GetLongPathName until we get to one that does exist. But I don't know if this is worth the hassle. After all, in the context of GDB, a file name recorded in the debug info could well cease to exist by the time GDB tries to canonicalize its name. > GetLongPathName, also, is not available on Windows 95. Is that an issue? I don't think so. > 2. Make lrealpath check for dirname existance only. The filename part will have to > be downcased on Windows. It doesn't need to be downcased: FILENAME_CMP copes with letter-case differences. > Now, which of those approaches you: > > - Will be willing to accept? Any one of them, actually. > - Will be willing to hack on, and push in libibery? "Willing", yes; "have time to", probably no.