James Youngman wrote:
> Paul> +static int
> Paul> +fts_compar (void const *a, void const *b)
> Paul> +{
> Paul>/* ... */
> Paul> + return pa[0]->fts_fts->fts_compar (pa, pb);
> Paul> +}
> ... compilers are likely to be able to inline the actual
> subroutine call away in any case.
How should t
Bruno Haible <[EMAIL PROTECTED]> writes:
> (I have not yet seen any platform where the ABI treats 'void *' pointers
> differently than any data pointers. The basic reason that 'void *' exists
> at all in C is to permit this kind of cast.)
The basic problem, as I understand it, is that some archit
On Mon, May 09, 2005 at 10:04:34PM +0200, Bruno Haible wrote:
Bruno> Paul Eggert wrote:
[...]
Paul> I installed this patch into coreutils.
Paul>
Paul> +static int
Paul> +fts_compar (void const *a, void const *b)
Paul> +{
Paul>/* ... */
Paul> + return pa[0]->fts_fts->fts_compar (pa, pb);
Paul>
Paul Eggert wrote:
> That reminds me; fts.c violates C89 in a couple of places, which could
> lead to core dumps on unusual hosts where void * and FTSENT const **
> have differing runtime representations. I installed this patch into
> coreutils.
>
> +static int
> +fts_compar (void const *a, void c
Jim Meyering <[EMAIL PROTECTED]> writes:
> I've hesitated to add coreutils' fts.c to gnulib partly because
> I didn't know of any other package that used it. Also, in order
> to remove some of those limitations, I had to change numerous types
> of fts.h's struct members. That means packages that
