[Top][All Lists]

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

Re: Bug#205949: vfat lost file problem

From: Jim Meyering
Subject: Re: Bug#205949: vfat lost file problem
Date: Tue, 19 Aug 2003 12:12:50 +0200

Paul Eggert <address@hidden> wrote:

> Jim Meyering <address@hidden> writes:
>> shouldn't the above two references to source_dirname
>> be to dest_dirname instead, because only the limits of the
>> destination directory are relevant?
> Either way should work, because when the code is executed we've
> already verified that the source and destination are the same
> directory.

Oh!  Of course <blush> :-)

> It makes the code clearer to use the destination directory, though.
> While we're on the subject of same.c, what do you think about the idea
> of assuming <stdlib.h>?  I notice a lot of occurrences of things like

I've been doing that little by little, and so far, no one has complained.
I think it's time to make the leap, so have just changed coreutils' system.h.

> HAVE_DECL_FREE -- is that because you still use hosts that don't have
> <stdlib.h>?  If so, you probably wouldn't like that part of the
> following patch:

I think it's time to make this sort of change, too.
No hurry.

> 2003-08-18  Paul Eggert <address@hidden>
>       * lib/same.c: Include <stdlib.h> and <string.h> unconditionally,
>         as we're now assuming that part of hosted C89.
>         (free) [!HAVE_DECL_FREE]: Remove decl; no longer needed.
>       (same_name): Invoke pathconf on destination, not source, as
>         that's a bit clearer even if they are the same dir.
>       * m4/same.m4 (gl_SAME): Do not check for stdlib.h or string.h or free.
>         Check for pathconf.

I've applied this.

reply via email to

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