On Tue, Jan 13, 2004 at 04:07:57AM -0500, Russell Yanofsky wrote:
> 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?
Depends on which IO interface you use. There's several of them.
I don't think it would create any problems for the perl bindings to
strip that. But I don't think it solves the problem. It hides it for
one situation that happens to be easier to work around and does nothing
for the rest.
> 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.
They largely let you do whatever you want when writing modules. There's
good and bad in this strategy. The good is there have been some very
nifty modules written that wouldn't otherwise be possible. The bad is
that it makes modules dependent upon impelementation details.
> 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.
This is not a unique problem to perl. If someone uses a library that is
using 64-bit off_t's when build their client and APR is using 32-bit
off_t's we're going to run into the same problem. Except this will be
harder to fix. It'll require that they rebuild APR and anything the
depends on it to use 64-bit off_t's. From when I was investigating I
didn't see any options for APR to enable this. I think you'd have to
use CFLAGS to get APR to do it.
> 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.
>
> 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.
I don't see APR fixing this issue happening in a timeframe that fits the
schedule we're trying to keep. And even then we'd have issues with
continuing to use a type name that was ambiguous. We'd have to require
that everyone use the latest version of APR that has the fix in order to
be sure that we weren't running into such an issue.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 13 19:53:05 2004