From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5726 invoked by alias); 8 Mar 2011 11:53:35 -0000 Received: (qmail 5702 invoked by uid 22791); 8 Mar 2011 11:53:34 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_05,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Mar 2011 11:53:28 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1PwvTi-0004AB-Mq; Tue, 08 Mar 2011 06:53:26 -0500 Date: Tue, 08 Mar 2011 12:01:00 -0000 Message-Id: From: Eli Zaretskii To: Kai Tietz CC: binutils@sourceware.org, gdb-patches@sourceware.org, gcc-patches@gcc.gnu.org In-reply-to: (message from Kai Tietz on Tue, 8 Mar 2011 12:25:37 +0100) Subject: Re: [patch libiberty include]: Add additional helper functions for directory-separator searching Reply-to: Eli Zaretskii References: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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: 2011-03/txt/msg00528.txt.bz2 > Date: Tue, 8 Mar 2011 12:25:37 +0100 > From: Kai Tietz > Cc: binutils@sourceware.org, gdb-patches@sourceware.org, > gcc-patches@gcc.gnu.org > > > Btw, why do we need filename_dirchr?  The use case for > > filename_dirrchr is clear, but in what situations will we need the > > other one? > > As the comment notes. strchr/strrchr searches for one character. This > is for unix-file-system normally slash. On DOS based file-systems > there are two characters representing a directory-separator. Slash and > Backslash. Therefore this routine takes care that both are handled > similiar to a single character searching. We are miscommunicating. I was asking when would a program want to find the _first_ directory separator character in a file name. Searching for the last one is a frequent use case: when you want to create a file in the same directory as another, or when you are looking for a basename of a file. But when do you need the first slash? > >> +  if (!r || (r2 && r2 < r)) > > > > Why do you test for r2 being non-NULL?  You are not going to > > dereference it in the next comparison, and NULL is comparable as any > > other value. > > As if we found slash, we don't want to override function's result by > backslash not found. If the null-check wouldn't be present condition > would be always true for r2 == NULL as, NULL is always less then a > pointer. But r shall be modified only if r2 (backslash) was found > before r (slash). > (same logic but here from right to left for the strrchr-case) But in strrchr-case, r2 cannot be greater than r1 if it is NULL, right?