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

Eli Zaretskii
2011-03-08T11:53:35Z

> 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?