Date: Mon, 21 Nov 2005 13:46:14 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Brian Candler <B.Candler@pobox.com> Cc: Tim Kientzle <kientzle@freebsd.org>, freebsd-current@freebsd.org Subject: Re: Order of files with 'cp' Message-ID: <20051121114614.GA1549@flame.pc> In-Reply-To: <20051120205605.GB19791@uk.tiscali.com> References: <20051116161540.GB4383@uk.tiscali.com> <437F7E22.5050800@freebsd.org> <20051120193416.GB1599@flame.pc> <20051120205605.GB19791@uk.tiscali.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2005-11-20 20:56, Brian Candler <B.Candler@pobox.com> wrote:
> On Sun, Nov 20, 2005 at 09:34:16PM +0200, Giorgos Keramidas wrote:
> > qsort() can be 'stable' enough for our purposes if the comparison
> > function uses something like this:
> >
> > int
> > compare_int32_t(void *pa, void *pb)
> > {
> > int32_t a, b;
> >
> > assert(pa != NULL && pb != NULL);
> > a = *((int32_t *)pa);
> > b = *((int32_t *)pb);
> >
> > if (a < b && pa != pb)
> > return 1;
> > if (a > b && pa != pb)
> > return -1;
> > return 0;
> > }
>
> Care to explain??
>
> For one thing, I don't think qsort() will ever call its
> comparison function with two equal pointers, as that would be a
> point(er)less thing to do. Therefore, I can't see why you are
> testing for pa != pb, since this condition will always be
> true. (Also, a < b could never be true if pa == pb).
I see. I was hoping to avoid spurious exchanges of `objects' in
cases like:
struct object {
int obj_value;
};
static struct object objvec[] = {{1},{1},{1}};
static struct object *vec[3] = {
&(objvec[0]),
&(objvec[1]),
&(objvec[2]),
};
where the comparison function may compare vec[k]->obj_value
elements and 'exchange' elements of vec[] because their value is
'equal' anyway.
But you're right this won't help, since qsort() never passes
equal pointers to the comparison function.
> Secondly, mastercmp() doesn't compare integers, it compares FTS
> structures. The comparison function just compares whether one
> item is a directory and the other a file. How would you have
> mastercmp() work instead?
To return to the problem at hand, the problem is that the
'sorting' function is allowed to re-arrange the order of argv[]
elements. I'd probably try to write mastercmp() in a way that
satisfies all of the following:
- All files are sorted before all directories
- Files are arranged by their argv[] order
- Directories are arranged by their argv[] order
This would probably require some sort of fts_number hackery, to
make sure we save the original order of argv[] elements, but I'm
not sure how to write a mastercmp() that works this way yet.
I'll have to check this more carefully
- Giorgos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051121114614.GA1549>