apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Hudson <ghud...@MIT.EDU>
Subject Re: Solving the off_t problem in APR 1.0
Date Fri, 23 Jan 2004 17:45:43 GMT
(Please keep me cc'd on replies, incidentally.)

Joe Orton wrote:
> 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.

Won't that create an ABI time bomb for platforms which have no
large-file support now, but acquire it in the future?

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

Yes, but it's internal messiness.  Even if we just truncate for now,
that's something we can fix in the future without creating an ABI

> Why "notably Linux", you keep saying that?

Because Linux is a more mainstream platform, at least from the
viewpoint of APR-using projects, than the others.  The point is to
show that this is not just a problem for some relatively obscure

> The final LFS spec was published in 1996, Solaris implemented it in
> 1997 at least, Linux distributions only started supporting it around
> 2000.

I think Linux implemented its own non-standard API (loff_t, llseek(),
etc.) earlier than that.  Not easy for me to check.

> 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.

That may be so; I wasn't aware that perl had its own Off_t type.

View raw message