[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: Kean Johnston <jkj_at_sco.com>
Date: 2004-01-12 13:16:55 CET

> The problem is pretty clear. Some compliations might have be a 64-bit
> int and some might be a 32-bit int. In my case perl bindings are
> picking up the 64-bit off_t form perl via the SWIG_PL_INCLUDES variable.
> libsvn_client sees it as 32-bit, the bindings see it as 64-bit. This is
> a problem.
Although I agree its a problem, which may well be addressed by changing
the particular usage you encountered to an unambiguous type such as
apr_uint32_t, I think the real error is in how you are compiling svn. If
you have decided to use the Perl bindings then you should compile svn in
the same approximate environment that Perl was compiled in. This
includes subtle things like _FILE_OFFSET_BITS, as well as other things
such as FD_SETSIZE or other nasty things that can trip you up if they
are set to different values in different applications. Likewise things
like threading.

There is an implied contract between the Perl distribution and its
users. If you want to use Perl in your app, you have to play Perl's
game. The same can be said for Python, Tcl, SLang, or any other library
for that matter. These days, you get to make an almost universal choice
for your platform. You either compile everything with 64bit support or
nothing, or else you do everything twice and get to futz around with
library paths.

Another popular library you may run into this exact problem with is
libz. It also defines z_off_t in terms of off_t, which makes calls to
thinks like gzseek() dangerous if you mix and match _FILE_OFFSET_BITS
values betwwen the app that uses it and the way the library was compiled.

In an ideal world, every application or library that needed offsets
would be sensitive to _FILE_OFFSET_BITS and provide both whatever32 and
whatever64 functions, and switch between them as needed. This is not an
ideal world :)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 12 13:18:28 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.