apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <...@manyfish.co.uk>
Subject Re: Solving the off_t problem in APR 1.0
Date Fri, 23 Jan 2004 12:18:44 GMT
On Thu, Jan 22, 2004 at 06:10:18PM -0500, Greg Hudson wrote:
> I'm going to propose fixing apr_off_t at 64 bits regardless of the
> system off_t.  This is not about getting large-file support in APR,
> although that could come as a side-effect; this is about helping
> APR-using libraries to be compatible with two different universes of
> libraries, and making APR itself compatible with those two universes.

The goal here is really that the size of apr_off_t should not be
affected by the _FILE_OFFSET_BITS definition on 32-bit platforms with
LFS support, which is an admirable goal.  I think the best way to
achieve this is to define apr_off_t as off64_t on such platforms, rather
than unconditionally change apr_off_t everywhere, and add LFS support to
APR: most of this work is already done inside #ifdef NETWARE anyway.

Using interfaces which take a 32-bit off_t from a 64-bit apr_off_t
sounds like it will be messy.

> I'll start at the beginning.  32-bit operating systems wanted to add
> large-file support.  The *BSDs did this by accepting a little bit of
> pain, revving their libc ABI major versions, and winding up with off_t
> being 64 bits.  Other platforms, notably Linux/x86, did not want to
> accept this pain, so they did two things:

Why "notably Linux", you keep saying that?  The final LFS spec was
published in 1996, Solaris implemented it in 1997 at least, Linux
distributions only started supporting it around 2000.

> Okay, now enter Perl.  Perl, which has always had a certain myopia
> when it comes to ABI issues, compiles itself with the magic 64-bit
> off_t flags on the relevant platforms.  As a consequence, any code
> which interfaces to perl (either as bindings or by embedding a perl
> interpreter) potentially also needs to compile itself with those
> flags, and any code which interfaces to that code (as caller or
> callee), and so on.  It was a mistake, but not a mistake that Perl can
> easily undo.  Possibly other packages have made the same error.  There
> are two non-empty universes of libraries and it hurts when they
> collide.

I don't believe fixing Perl is rocket science: it too should just use 
the transitional API, use off64_t for its Off_t, etc.



View raw message