apr_size_t (was: Re: CVS update: ...)

On Thu, Nov 09, 2000 at 02:22:15PM -0600, Karl Fogel wrote:
> Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> > If APR is our portability layer, then let's be pedantic about it and use
> > the APR types everywhere. I prophesy this will save us some grief later on.
>
> Mmm -- yes, why doesn't APR itself use AC_TYPE_SIZE_T and get rid of
> `apr_size_t'?

Partly historical, partly necessary.

Consider if a client app uses size_t, but the platform doesn't happen to
have it. The app breaks unless it happens to include apr.h. Of course, the
app is just using "size_t" (rather than apr_size_t), so it didn't know to
include apr.h.

Okay, now we decide to fix the app by putting an AC_TYPE_SIZE_T into its
configuration. Oops. Now that one conflicts with the size_t definition found
in apr.h.

You'll note that APR hides all of its autoconf macros (e.g. HAVE_LIMITS_H)
in apr_private.h. It does export some of them by defining them as
APR_HAVE_LIMITS_H in apr.h (by generating them during the apr.h.in -> apr.h
process). This allows APR to be well-behaved within another autoconf
application.

[ After recalling this conflict issue... ]

I'd recommend that we continue to use apr_size_t and apr_ssize_t rather than
going the AC_TYPE_SIZE_T route.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/