(This e-mail will use apr_size_t throughout. The same applies to apr_off_t and apr_ssize_t, and possibly other types).
I was going to stay out of this, but I decided not to. apr_off_t and apr_size_t and any other types like them are incorrectly defined in APR today. The problem is that they are defined in terms of what the OS thinks the correct size should be, which as we are seeing with LARGEFILE support, changes quite often. In the very first incarnation of APR, apr_size_t was defined as an apr_intx_t, which meant that it had a constant size on all platforms. Then, we had the problem that when we needed to pass that to the native function, sometimes we had the wrong size integer. To fix this, we tied apr_size_t to size_t. IMNSHO, that was the wrong solution. We should have kept the original apr_size_t defined as a specific size, and dealt with changing the type in the APR code itself. That way, the code is more portable, because rather than having different platforms use different sizes for apr_size_t, the API for APR is consistant across all platforms. This also means that the user should generally be able to ignore APR_HAS_LARGEFILES, because if it is defined, then we use the largefile support in the platform, otherwise we don't. But, the user isn't exposed to that difference when using APR functions. Ryan Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>: > At 06:03 PM 3/25/2004, Joe Orton wrote: > >On Thu, Mar 25, 2004 at 03:49:09PM -0800, Stas Bekman wrote: > >> > >> That's a bad idea, IMHO, because ARP_HAS_LARGE_FILES will still report > >> false. You suggest to create a mess, where the library will report one > >> thing but behave as another. > > > >I was thinking about this today as well... what do you expect > >APR_HAS_LARGE_FILES to actually mean? "sizeof(apr_off_t) > > >sizeof(apr_size_t)"? or "sizeof(apr_off_t) > off_t"? or > >sizeof(apr_off_t)==8? Any of these are trivial to implement in the > >configure script. > > .02 euro (worth more than US 2c) from the guy who invented the flag? > > APR_HAS_LARGE_FILES means that an apr_off_t is bigger than > all addressable memory (size_t). You can't fit the apr_off_t into any > [apr_][s]size_t placeholder. > > Honestly I dont care if there is any relationship between óff_t and > apr_off_t, otherwise why did we define our own type? It's (possibly) > an implementation dependent detail but otherwise irrelevant. > > Bill > > >
