Re: [bug-gnulib] New GNULIB glob module?

[Paul Eggert]

Derek Price <address@hidden> writes:

> all the HAVE_.*64 stuff in glob.c shouldn't be necessary when !_LIBC.

Yes, that's correct; it should just invoke stat, opendir, etc., without
worrying about their 64-bit variants.  I thought it already did that?
If not, where does it not do it?

> Also, this particular bit in glob_.h would need to be used when !_LIBC
> as well, since user-space programs compiling against the glob.h system
> header from glibc would want glob64 used as compile-time magic, correct?

Sorry, you've lost me here (I don't know what "this particular bit"
is).  If !_LIBC, then glob_.h should simply declare glob and globfree,
using the standard (i.e., non-64-bit) type names.  These functions
will use 64-bit types if they are available, but the user code will
too and the user code won't need to worry about this.  I had thought
that this is what the code did already.


> Please excuse me if this is way off, I don't have much experience at the
> 64-bit file offset stuff, myself.

The basic idea is that GNU applications never need access to names
like stat64, open64, etc.  They just invoke stat and open.

The only reason for stat64 and open64 is for support of mixed
applications, where some of the code uses 32-bit interfaces and other
code uses 64-bit.  This is useful when you don't have access to the
source of legacy code that knows only about 32-bit interfaces.  But
GNU programmers have access to the source code, so we can simply
recompile it to use 64-bit interfaces uniformly, which we can then
simply call via their usual names stat, open, etc.


> One thing that leads me to believe I may be wrong is that it looks
> like the glob64 from glibc 2.3.5 is only a stub function.

I don't remember the details, but I vaguely recall that glob64 was a
mistake.  Let's not worry about it for gnulib.