bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: This week's NEWS


From: leslie . polzer
Subject: Re: Fwd: This week's NEWS
Date: Sun, 3 Jun 2007 12:05:28 +0200
User-agent: mutt-ng/devel-r804 (Linux)

On Sun, Jun 03, 2007 at 09:25:58AM +0100, James Youngman wrote:

> It's a hangover from the days when we used to use basename(). The
> basename() function does not allocate memory. The fact that the buffer
> returned by base_name() is not freed is not intentional. I'm sure the
> same problem affects both 4.3.x and 4.2.x. If you fix it, could you
> mail it to me as a separate patch?

Sure thing.


> [xattr & ext2attr]
>
> Do they need to be two separate predicates?

They probably should.  They don't really have a lot in common with XFS
extended attributes, not even the name.


> The reason for this is that find may or may not change CWD as it goes,
> depending on which binary you are running and how it is configured
> (e.g. the value of ftsoptions in ftsfind.c, the availability of
> /proc/N/fd, and whether you are running the "find" or "oldfind"
> binary).

Yuck.  But ignoring ENOENT is not the right way to handle this, is it?


> The hacking with run_in_dir() is not always necessary if the OS or
> gnulib provides a *at() function, like fstatat(). But the pathname you
> pass to such functions in any case needs to be state.rel_pathname.

Okay, thanks.  Will do so.

  Leslie

-- 
Personal homepage: https://viridian.dnsalias.net/~sky/homepage/
gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83

Attachment: pgpF3eaGgKq8X.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]