[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:21:45 CET

On Mon, Jan 12, 2004 at 04:16:55AM -0800, Kean Johnston wrote:
> 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 :)

It was a standard distro perl. Every single user of Mandrake on a
32-bit platform (and possibly others) would end up with this problem
unless they go out of their way to do some hoop jumping to handle this.
I did nothing extra to tell it to use _FILE_OFFSET_BITS, the build
system is picking that up automaticaly from Perl via:
perl -MExtUtils::Embed -e ccopts

Most users are not going to be aware of _FILE_OFFSET_BITS. You're
suggesting that users should be aware of that, aware of how their perl
was compiled and know that they should pass a
CFLAGS=-D_FILE_OFFSET_BITS=64 to the configure?

I'm sorry but that just seems a tad crazy to me. Certainly doesn't seem
user friendly. But then considering the company you're keeping, I guess
I shouldn't be surprised.

Ben Reser <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:22:43 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.