In that case, I would prefer to use `size_t', so as not to confuse
people into mistakenly thinking that something special is going on.
Subversion is only meant for ANSI C, and `size_t' is ANSI, so as far
as Subversion is concerned, it's always okay.
If APR's target audience is also ANSI C (which it appears to be,
judging from the function prototypes), then probably APR could safely
get rid of `apr_size_t' too, and for the reasons given above I think
that would be a good idea.
(Of course, it should still define it to size_t, for backwards
compatibility, but it wouldn't have to document it nor encourage its
use anymore.)
-K
Greg Stein <gstein@lyra.org> writes:
> On Tue, Nov 07, 2000 at 12:55:45AM +0100, Branko Cibej wrote:
> > Karl Fogel wrote:
> > >> By the way, shouldn't that parameter be `apr_size_t'?
> > >
> > > I'm not really sure what the advantage/disadvantage would be. (?)
> >
> > Oh well, no advantage as such, just consistency. Do we want to be
> > consistent about using APR types? I'd say yes, if it doesn't cost a lot,
> > but It's not my call.
>
> apr_size_t exists in case some whacko platform doesn't have a size_t in its
> header files. Dunno any, but the need was discovered by Apache (at some
> point in the past) and it just flowed into APR.
>
> My guess is that it isn't really needed any more.
>
> I'm with Branko on this one: let's use apr_[s]size_t consistently.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:14 2006