[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: apr_off_t is of an ambiguous size.

From: Russell Yanofsky <rey4_at_columbia.edu>
Date: 2004-01-13 10:07:57 CET

Ben Reser wrote:
> On Mon, Jan 12, 2004 at 08:22:06AM -0500, Russell Yanofsky wrote:
>> 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?
>
> Automatically picked up by the subversion build system with:
> perl -MExtUtils::Embed -e ccopt

Is it possible to just strip out -D__USE_FILE_OFFSET64 from what it returns?
Or do the perl APIs use off_t in their own interfaces?

It seems the perl people have screwed up in making extension developers
build with non-standard library options. It would be fine if they just used
the __USE_FILE_OFFSET64 macro internally to do 64 bit I/O on Linux, but they
aren't right to try to impose their implementation detail on everybody else.

This problem should be addressed in the perl bindings itself. It should not
be passed on to Subversion or APR. If stripping out the macro definition is
not enough to deal with the problem, then you can create a little
intermediate library in the perl bindings compiled without perl options,
that forwards calls to the handful of functions that use apr_off_t, and uses
apr_int64_t in it's own interface.

>> 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.
>
> That would work I guess but that's not consistent with what APR is
> doing

How is that not consistent with what APR is doing? APR is a platform
compatility layer. It's whole purpose is to provide a platform neutral
interface that works on multiple platforms. There is no reason to hardcode
64 bit types into a generic file i/o interface.

> and I don't think it's a good idea for us to go around redefining apr
> types.

I'm not proposing that. In your original post you seemed to suggest that the
apr interface needed be changed to address this problem. I disagree with
that. This is a linux specific problem and if anything at all is needs to be
changed in APR to address it, the changes should be limited to the linux
implementation.

- Russ

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 13 10:05:35 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.