bug-gnulib
[Top][All Lists]
Advanced

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

Re: unsafe use of dirfd in fts.c, getcwd.c, glob.c?


From: Jim Meyering
Subject: Re: unsafe use of dirfd in fts.c, getcwd.c, glob.c?
Date: Mon, 13 Sep 2010 13:41:25 +0200

Paul Eggert wrote:
> On 09/12/2010 10:25 PM, Jim Meyering wrote:
...
>> The POSIX wording allowing dirfd to fail on a valid stream is far older
>> than the *at functions, for which dirfd can now be essential.  Given this
>> relatively new constraint, the odds of any new, useful system providing
>> a stream interface without a backing file descriptor are nil.
>
> I am hoping you're right (it does match my experience and
> expectation).  If so, we don't need to "fix" getcwd.c and glob.c,
> and we can simplify GNU tar along the lines you suggested.
> But also, can't we simplify fts.c slightly, as follows?
>
> --- old/fts.c 2010-09-12 23:32:51.672822000 -0700
> +++ new/fts.c 2010-09-12 23:48:51.004174000 -0700
> @@ -1302,7 +1302,7 @@ fts_build (register FTS *sp, int type)
>           */
>          if (nlinks || type == BREAD) {
>                  int dir_fd = dirfd(dirp);
> -                if (ISSET(FTS_CWDFD) && 0 <= dir_fd)
> +                if (ISSET(FTS_CWDFD))
>                    {
>                      dir_fd = dup (dir_fd);
>                      if (0 <= dir_fd)

I'm reluctant to remove that as long as there's
still a chance mingw users will care.

That getcwd.c and glob.c assume dirfd always succeeds
and no one has complained about failures
make me think that no mingw application can be using that code.

Still, it would be good to fix those, if for no other reason than to
save some other reviewer the trouble of finding and reporting them again.



reply via email to

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