Re: [patch libiberty include]: Add additional helper functions for directory-separator searching

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 8 Mar 2011 12:25:37 +0100
> From: Kai Tietz <ktietz70@googlemail.com>
> 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?