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

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

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

Mime
View raw message