[Top][All Lists]
[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.
- [bug-gnulib] stat and lstat should define their replacements, Derek Price, 2005/05/24
- Re: [bug-gnulib] stat and lstat should define their replacements, Paul Eggert, 2005/05/25
- Re: [bug-gnulib] Re: [bug-gnulib] stat and lstat should define their replacements, Bruno Haible, 2005/05/25
- Re: [bug-gnulib] Re: [bug-gnulib] stat and lstat should define their replacements, Derek Price, 2005/05/25
- [bug-gnulib] Re: stat and lstat should define their replacements,
Jim Meyering <=
- [bug-gnulib] Re: stat and lstat should define their replacements, Paul Eggert, 2005/05/27
- [bug-gnulib] Re: stat and lstat should define their replacements, Bruno Haible, 2005/05/27
- [bug-gnulib] Re: stat and lstat should define their replacements, Derek Price, 2005/05/27
- [bug-gnulib] Re: stat and lstat should define their replacements, Paul Eggert, 2005/05/27
- [bug-gnulib] Re: stat and lstat should define their replacements, Jim Meyering, 2005/05/28
- [bug-gnulib] Re: stat and lstat should define their replacements, Bruno Haible, 2005/05/30
Re: [bug-gnulib] stat and lstat should define their replacements, Derek Price, 2005/05/27