From: Pierre Habouzit <madcoder-zi3NMfd+bKEdnm+yROfE0A@public.gmane.org>
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ulrich Drepper <drepper-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [Bug libc/11459] New: ftw doesn't work like documented (may be a documentation bug)
Date: Wed, 9 Jun 2010 12:46:29 +0200 [thread overview]
Message-ID: <20100609104629.GA2340@madism.org> (raw)
In-Reply-To: <AANLkTinhGzNB_dabQcan3c1nQuGwkaTIBAVZuRO2dJty-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Jun 03, 2010 at 09:18:22AM +0200, Michael Kerrisk wrote:
> Hi Pierre,
>
> On Wed, Jun 2, 2010 at 11:42 PM, Pierre Habouzit <madcoder-zi3NMfd+bKEdnm+yROfE0A@public.gmane.org> wrote:
> > On Mon, May 24, 2010 at 07:41:49PM +0200, Michael Kerrisk wrote:
> >> Hello Pierre,
> >>
> >> On Tue, Apr 6, 2010 at 11:03 AM, Pierre Habouzit <madcoder@madism.org> wrote:
> >> > See below a bug reported against the glibc. Since the glibc maintainer
> >> > dodged that one, I assume the bug indeed is in the documentation of
> >> > ftw(3). My manpages are the 3.24-1 Debian package.
> >>
> >> Yes. The man page is clearly incorrect. Thanks for reporting this.
> >>
> >> > IMHO the patch is:
> >> >
> >> > -fpath is the pathname of the entry relative to dirpath.
> >> > +fpath is the pathname of the entry relative to the current working directory.
> >> >
> >> > POSIX is very vague about what "fpath" should be btw.
> >>
> >> (Agreed. It could be more precise.)
> >>
> >> I believe the correct text should be this:
> >>
> >> fpath is the pathname of the entry, and is
> >> expressed either as a pathname relative to the
> >> calling process's current working directory at the
> >> time of the call to ftw(), if dirpath was expressed
> >> as a relative pathname, or as an absolute pathname,
> >> if dirpath was expressed as an absolute pathname.
> >>
> >> I have updated the man page accordingly, but would welcome
> >> review/checking of this text.
> >
> > Afaict, it's not correct: ftw may perform chdir() calls, so the pathname
> > is relative to the current working directory at the time `fn` is called.
> >
> > I'd rather phrase it that way (minus probable english mistakes):
> >
> > fpath is the pathname of the entry, and is either a relative
> > pathname to the current working directory of the application when
> > `fn` is called, or as an absolute pathname.
>
> Thanks for taking a look at this. However, I *think* your analysis is
> wrong, and my proposed changes is right. But, still I'd like some
> further confirmation. Please take a look at the the program below, and
> the output produced when it runs.
Yeah, that's because you're doing chdir()s during ftw, which is
undefined behaviour as documented in the manpage already IIRC.
The point is, ftw() /may/ decide to do chdir() by itself sometimes, and
then the path is relative to the current working directory as set by
ftw().
I'm pretty sure it's what POSIX authorizes ftw() to perform chdirs.
And when I look at ftw.c in the glibc, it's also pretty much what
happens in the case when you set FTW_CHDIR in the flags: ftw() forces a
chdir before the fn() call, and makes the path relative to this cwd.
It happens that the glibc doesn't seem to perform any kind of chdir() in
the other cases (IOW when FTW_CHDIR isn't set), but I'm pretty sure
POSIX allows ftw() to do so.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-06-09 10:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100403201146.28880.qmail@sourceware.org>
[not found] ` <20100403201146.28880.qmail-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org>
[not found] ` <20100331172608.11459.madcoder-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
2010-04-06 9:03 ` [Bug libc/11459] New: ftw doesn't work like documented (may be a documentation bug) Pierre Habouzit
[not found] ` <20100406090358.GP11893-FHnHQIk6zPswS4c7l5MyDw@public.gmane.org>
2010-05-24 17:41 ` Michael Kerrisk
[not found] ` <AANLkTim05fJpMXD1owEON-70WwxDUkxIvYIgkn7EfBEf-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-02 21:42 ` Pierre Habouzit
[not found] ` <20100602214257.GB21506-zi3NMfd+bKEdnm+yROfE0A@public.gmane.org>
2010-06-03 7:18 ` Michael Kerrisk
[not found] ` <AANLkTinhGzNB_dabQcan3c1nQuGwkaTIBAVZuRO2dJty-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-09 10:46 ` Pierre Habouzit [this message]
[not found] ` <20100609104629.GA2340-zi3NMfd+bKEdnm+yROfE0A@public.gmane.org>
2010-06-10 5:04 ` Michael Kerrisk
[not found] ` <AANLkTikWG4U2wWS6ccM98Mg32WNrVCu5QCmz46hQ7lCC-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-24 20:12 ` Pierre Habouzit
[not found] ` <20100624201216.GB5357-zi3NMfd+bKEdnm+yROfE0A@public.gmane.org>
2010-06-25 4:53 ` Michael Kerrisk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100609104629.GA2340@madism.org \
--to=madcoder-zi3nmfd+bkednm+yrofe0a@public.gmane.org \
--cc=drepper-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).