[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: apr_off_t is of an ambiguous size.

From: Ben Reser <ben_at_reser.org>
Date: 2004-01-12 18:25:31 CET

On Mon, Jan 12, 2004 at 10:02:22AM -0500, John Peacock wrote:
> Sorry, I am the one who noticed the problem, and I did exactly that. While
> debugging this, I literally built _everything_ from the ground up,
> including Perl, SWIG, Subversion, and the Perl bindings. If there is
> something special I need to do at any point with _FILE_OFFSET_BITS, et al,
> then the build system must be enhanced to do this, or else the bindings are
> useless to anyone not running a pure-64bit environment.
>
> It just so happens that Ben was developing with a 64bit pre-release version
> of Mandrake, so he didn't see the problem. I'm using a 32bit distro
> (currently a much more common environment), so although I can build Perl to
> use 64-bit ints, I shouldn't have to unless I want to for some other
> reason. I will, in fact, build a 64-bit aware Perl and see if that fixes
> it (as it should). But the larger issue of relying on an off_t that is not
> consistent is still a problem that needs solving.

It won't. The segfault is happening because the perl bindings are
expecting 32-bits more memory than the client library is actually giving
them. So when it goes to read the last parameter it reads past the end
of its memory.

It's not visable on a 64-bit platform because the size of a long and a
long long are identical. So despite the different data types there's no
difference.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 12 18:26:13 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.