[Top][All Lists]

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

Re: [Bug-gnulib] lstat/stat

From: Jim Meyering
Subject: Re: [Bug-gnulib] lstat/stat
Date: Tue, 10 Jun 2003 19:27:18 +0200

Regarding this:

Derek Robert Price <address@hidden> wrote:
> I've attached a patch for the lstat half of the stat replacements.
> The main problem this addresses is that on systems where lstat has
> problems with trailing slashes, AC_LIBOBJ(lstat) is called by
> AC_FUNC_LSTAT.  The jm_FUNC_LSTAT macro used to check an sh variable
> set by AC_FUNC_LSTAT before calling gl_PREREQ_STAT and miss the case
> where AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK found the problem.  This
> causes compiler errors when compiling lib/stat.c since the
> gl_PREREQ_LSTAT macro was never called.
> I also tweaked stat.c to not compile the slash-safe lstat unless
> configure actually detected that the system didn't treat slashes as
> we'd like.
> The patch is against the CVS tree, but it should apply to GNULIB
> without a problem since the layout is the same.

Hi Derek,

Thanks for investigating that!
And sorry it's taken so long for me to reply.

Do you know if it'd solve the problem to make the prerequisite tests
unconditional?  I really hope so, because using cache variable names
from other tests makes the code very fragile -- I've been burned by
that too many times.  Even using cache variables defined in the same
file has been known to throw me :-)

I do see why that prerequisite-testing is conditional,
and agree in principle with the general goal.
However, it'd be much better if macros like AC_FUNC_LSTAT and
AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK took optional `run-if-true'
and `run-if-false' arguments.  Then we wouldn't need to rely on
fragile cache variable names.

I've Cc'd the autoconf discussion list.
If no one objects, I'll change the stat/lstat-related AC_
macros as I've suggested.


reply via email to

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