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.

Regards,

joe

Mime
View raw message