apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Reser <...@reser.org>
Subject Re: Solving the off_t problem in APR 1.0
Date Thu, 29 Jan 2004 00:45:27 GMT
On Wed, Jan 28, 2004 at 10:34:41PM +0000, Joe Orton wrote:
> One possible minor issue with this patch:
> 
> if a C++ library based on APR uses apr_off_t in its API, I believe that
> changing apr_off_t from a long to an int changes the ABI of that
> library, because of the name mangling stuff.
> 
> I don't know of any C++ libraries based on APR, and fixing the
> incompatibility with Perl is probably far more important anyway.  Ignore
> it?

D'oh, I'm tempted to say ignore it.  But I know rapidsvn is using C++ so
this would probably break rapidsvn if you upgrade APR/httpd2 with this
change in the future.  Which I think would be kinda bad. 

> We could fudge apr_off_t to still be a long on platforms where it was
> already or even on all platforms with a 32-bit long if anyone really
> cares.  It might be wise anyway... could compilers specify different
> structure padding/alignment/calling conventions for int and long even
> though they are the same size? Hmmm... 

I doubt the compiler treats int or long any different on the platforms
where they're the same size.  I see people misuse int in place of long
and it works fine until they port it to another platform, where it isn't
the same size.  This is a big reason why moving code over to 64-bit
archs has been such a hassle.

So I guess I'll look into redoing it to use int, long or long long
instead.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org

"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken

Mime
View raw message