Re: Yet another look at the apr_off_t problem

On Sat, Jan 24, 2004 at 01:51:11AM +0100, Tobias Ringström wrote:
> The only real problem is that the size of apr_off_t is variable
> depending on compiler options (because it is an off_t typedef).
>
> Greg Hudson proposed to make apr_off_t 64 bit, but the drawback of doing
> so is that it cannot be done for apr 0.9 because the ABI would change.
> Another appealing solution is to simply modify apr to make the size of
> apr_off_t fixed to the size of off_t when apr is compiled. What I'm
> saying is that apr should have an autoconf test to find out the size of
> off_t, and use that size when creating the apr_off_t typedef.
>
> Right now it is
>
> typedef off_t apr_off_t;
>
> but after such a change it should be something like
>
> #if APR_HAS_32BIT_OFF_T
> typedef apr_int32_t apr_off_t;
> ...
>
> if autoconf finds out that off_t is 32 bit at the time when apr is
> configured and compiled.

To clarify for people that didn't understand what he means here... Let
me give a simple explanation of the problem.

apr_off_t is typedefed from off_t. off_t on some platforms can be a
32-bit or 64-bit integer depending on compile time flags.

If the compile time flags for when APR is built and a program using APR
is built differ then there can be an ABI incopatability.

The change proposed here would shift the determination of the size of
apr_off_t from when any code using it is built to when APR is built.

If the compile time flags for APR make the platform provide it a 32-bit
off_t then APR would typedef apr_off_t as:
typedef apr_int32_t apr_off_t

If the compile time flags for APR makes the platform provide it a 64-bit
off_t then APR would typedef apr_off_t as:
typedef apr_int64_t apr_off_t

Even if an application built with an off_t of a different size than what
APR was built with apr_off_t would always be the same size as APR thinks
it is. The ABI is preserved.

> The advantage of doing this is that we can release Subversion right now
> without changes. With current apr, the perl bindings will be broken,
> but when compiled with a fixed apr, they will just work.
>
> The drawback is of course that someone need to change apr, and I don't
> know who easy that is, or how fast it can be done.
>
> Does this sound like a plan or what?

This would be an acceptable solution. Iff APR is willing to make such a
change.

So how about the following:

Make the blame fix because the line_no parameter doesn't make any sense
being an apr_off_t type. We change that to apr_uint64_t. We put that
in 0.37.0. This fixes the blame problem.

We don't do anything about any of the other issues in 0.37.0. We try
and work with the APR people to fix the issue in APR during the soak
time. If it becomes clear that such a solution isn't acceptable to APR
then we'll have to revist the issue, decide what our options are from
there, and what if any impact those options have on the 1.0 release.

Sound fair?

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