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: svn commit: r368769 - /apr/apr/trunk/include/apr_file_io.h
Date Fri, 13 Jan 2006 18:59:20 GMT
Mladen Turk wrote:
> Garrett Rooney wrote:
> 
>>>
>>> URL: http://svn.apache.org/viewcvs?rev=368769&view=rev
>>> Log:
>>> Mark pool param for apr_file_remove and apr_file_rename
>>> as unused (because it is).
>>> Perhaps some day it will be removed from the API.
>>
>>
>> I'm not sure how I feel about this.  The pool could potentially be
>> used for temporary allocation some day, if we port to a platform that
>> happens to require it.  Encouraging people to just pass random things
>> in place of the pool argument seems like a bad idea.
>>
> 
> Right, make sense in that case.
> There are also few other functions that have pool
> as a param but never use it like
> apr_env_delete or apr_dir_remove.

Adding the "unused" param is useful, but of course it's compiler
specific how we code it, so we may need some autoconf foo to make it
truly portable. That said, having the compiler know it's unused seems
like a sensible goal to me rather than removing them.

> The question is if they'll be ever used, or particularly,
> can someone write the implementation without using pool.
> Since the return value from those functions is int, I'm
> almost sure they could be, by using stack for temp storage,
> and further more since no additional object is created that would
> require cleanup.
> 
> I think they were simply over engineered initially.

Perhaps.

> 
> Regards,
> Mladen.


Mime
View raw message