bug-gnulib
[Top][All Lists]
Advanced

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

[bug-gnulib] Re: stat and lstat should define their replacements


From: Jim Meyering
Subject: [bug-gnulib] Re: stat and lstat should define their replacements
Date: Thu, 26 May 2005 09:30:27 +0200

Bruno Haible <address@hidden> wrote:
> Derek Price <address@hidden> writes:
>> As near as I can tell, stat and lstat do not define names for their
>> replacements as many of the other GNULIB modules do.
>
> Yes. The 'stat' and 'lstat' modules look incomplete. I think this should
> be added to make them usable out-of-the-box.
...
> + /* gl_stat() is a fixed version of stat().
> +    gl_lstat() is a fixed version of lstat().
> +    We cannot offer a stat() and lstat() function because on some hosts,
> +    a "#define stat stat64" and "#define lstat lstat64" is being used.  */
> +
> + #if HAVE_STAT_EMPTY_STRING_BUG
> + extern int rpl_stat (const char *name, struct stat *buf);
> + # define gl_stat(name,buf) rpl_stat (name, buf)
> + #else
> + # define gl_stat(name,buf) stat (name, buf)
> + #endif
> +
> + #if HAVE_LSTAT_EMPTY_STRING_BUG || !LSTAT_FOLLOWS_SLASHED_SYMLINK
> + extern int rpl_lstat (const char *name, struct stat *buf);
> + # define gl_lstat(name,buf) rpl_lstat (name, buf)
> + #else
> + # define gl_lstat(name,buf) lstat (name, buf)
> + #endif

But isn't that implicitly saying that all packages using gnulib
should use gl_lstat and gl_stat rather than lstat and stat?

That's pretty extreme, and contrary to one of the most fundamental
goals of gnulib: let people code to the best/most-accepted interfaces.
The idea is to make converting a package to gnulib as painless as
possible, and to make it so future maintainers don't have to remember
to use e.g., gl_stat everywhere they would normally use stat.
We should try hard not to let the bugs of a few broken systems
push us into polluting our interfaces with the work-arounds.
That's why there has been such an emphasis on using wrappers
that are as transparent (from the bodies of the calling functions)
as possible.

I followed the recent `include-last'-headers-are-bad thread, and agree
in general, but nonetheless, I suggest an include-last (or at least
after-sys/stat.h) header that undef's and defines the names lstat
and stat.  This minor restriction seems far more palatable than
performing s/lstat/gl_lstat/-style global substitutions in every
package that uses gnulib.  coreutils' ls.c and remove.c have been
defining `lstat' for years.  I noticed that remove.c doesn't have
the #undef -- but that's fine, since it doesn't include <sys/stat.h>
either.

BTW, I suspect that testing for the HAVE_LSTAT_EMPTY_STRING_BUG
code isn't useful anymore.  It works around bugs in SunOS4.1.4
and vintage Hurd (1998 or 1999, presuming it was fixed back then).
IMHO, SunOS4.1.4 stopped being a reasonable portability target a
couple of years ago.




reply via email to

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