Derek Price <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
