Ben Reser wrote:
> ...
> apr_off_t is just a typedef to off_t. Which on Linux is defined in
> sys/types.h as:
> # ifndef __USE_FILE_OFFSET64
> typedef __off_t off_t;
> # else
> typedef __off64_t off_t;
> # endif
>
> The problem is pretty clear. Some compliations might have be a 64-bit
> int and some might be a 32-bit int. In my case perl bindings are
> picking up the 64-bit off_t form perl via the SWIG_PL_INCLUDES
> variable. libsvn_client sees it as 32-bit, the bindings see it as
> 64-bit. This is a problem.
I don't understand. Are you defining __USE_FILE_OFFSET64 somewhere in the
perl bindings? Isn't the solution to just use the same library settings
across all parts of subversion?
> Looking at the headers we're using apr_off_t in svn_diff, svn_io and
> svn_client (for the blame receiver). By only have a 32-bit apr_off_t
> we're crippling ourselves in the long run for large file support and
> making interoperating with the growing number of libraries that do
> have it difficult.
>
> Unfortunately, APR doesn't turn it on. Nor does apr provide us with
> an apr_off64_t. I would guess it doesn't try to turn it on because it
> can't be reliably done on all platforms.
>
> We can't just ignore the issue because we have an ambiguous data type
> in our interface. Even if APR adds support apr_off_t will still
> probably be ambiguous. Only a new type of apr_off32_t and
> apr_off64_t would be unambiguous. So if/when APR fixes this we'd be
> left with an API change.
The nice thing about apr_off_t interfaces over off32 and off64 interfaces is
that apr_off_t interfaces can work ideally on all platforms whether they
support 64-bit files or not.
If apr has to be changed to avoid this ambiguity, a better way to do it
would be to define
typedef off64_t apr_off_t;
unconditionally on linux and have it use 64 bit functions like lseek64
internally.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 12 14:20:01 2004