William A. Rowe, Jr. wrote: > Davi Arnaut wrote: >> Bojan Smojver wrote: >>> On Wed, 2007-06-06 at 09:38 +1000, Bojan Smojver wrote: >>> >>>> testlfs : Line 265: Large Files not supported >>> Or is this just a misleading message saying "these things are enabled by >>> default on this platform"? >>> >> Good question. LFS doesn't exist for 64 bit platforms, but because it >> supports large files out of the box. This leads to another question, >> should APR_HAS_LARGE_FILES be defined on 64-bit systems? It seems >> reasonably safe to do so. > > I've always understood HAS_LARGE_FILES to mean that offsets don't fit > into a size_t alignment, they are larger offsets than are otherwise > represented in memory. The thought that apr_off_t > off_t might also > fit that bill.
As a user of the library, i would thought that with HAS_LARGE_FILES apr_off_t is guaranteed to be 64 bits long. I wouldn't care about off_t, since that's not portable. > But no, we should probably figure out how to report this case more > intellegently in testlfs so people don't panic. LARGE_FILES, imho, > should not be set where special handling of the file offsets didn't > happen. I think that APR_HAS_LARGE_FILES should be defined whenever we have a 64 bits long apr_off_t, because that's probably what the user want to know -- if the platform supports large files, which is true for 64 bit systems. On 32-bits with LFS we should define an internal macro for special handling of the file offsets. For example, testlfs.c is perfect fine and should run on 64 bits platforms. Although not a urgent issue, we should clarify and document better the APR_HAS_LARGE_FILES meaning. -- Davi Arnaut
