Well, there is ANSI C (the syntax/compiler), and then there are the
libraries. While we can easily require an ANSI C compiler (and we do), the
library/headers is possibly a different issue.
apr_size_t's presence signals the fact that at some point, size_t was NOT
available somewhere.
Cheers,
-g
On Mon, Nov 06, 2000 at 04:44:50PM -0600, Karl Fogel wrote:
> 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/
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:14 2006