apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <da...@jetnet.co.uk>
Subject Re: [REVIEW] issues for 1.0
Date Tue, 15 Jun 2004 09:59:37 GMT
> > - we need to decide if Ryan's proposed fix to the mutex_child_init
> > stay or we stick with existing api. I've not been involved in it
> > BUT can we have some votes as otherwise I'll stick with what we have.
> My preference is to wait on this.  I think making such a drastic change
> *right* before we go to 1.0 is asking for trouble.

If we're happy that the API we have is fine, then we don't need a change.
There seems to be a feeling it's not.

Your strawman patch and Ryan's seem to be the 2 solutions proposed. We need
to move this forward.

> > - namespace protection in headers. Where do we stand on this? apr.hnw is
> > listed in STATUS?
> Realistically, I consider this a *yawn*.  We could fix this up later, I


> > - thread return types. I see 2 +1's already for changing the type to an
> > apr_status_t. Anyone else care to comment/vote?
> I thought it wasn't portable to return a thread exit value on all OSes.
> sure, I guess it sounds reasonable.  +1.

Again we need to decide if we're gonna do this as it'll be a change to the

> > - version to apr_initialise. I see enough 3 +1's, but a -1 and a -0, so
> > comments?
> I think it's a good idea, but Greg with his -1 (veto) needs to chime in.


> > - apr_md5 functions. Should they change to void? Move to apr-util?
> MD5 already moved to apr-util.  But, the return type is still
> Yet, I don't see a particularly compelling reason to change this to void.

Just seems a little pointless to return a status for functions that don't
have a success/fail.


View raw message