obsolete functions?

[Max Kellermann <ma...@duempel.org>]

I noticed the following functions, but couldn't explain their use in
libapreq2:

 apreq_quote
 apreq_quote_once
 apreq_memmem

apreq_quote is used by apreq_join with APREQ_JOIN_QUOTE, but I do not
see yet how this option helps apreq2. apreq_memmem is not used at all.

Why are both apreq_encode and apreq_escape exported? apreq_encode is
potentially unsafe - you need a 3*length+1 buffer in the worst case;
this is not explicitly documented. We should only export the safe
equivalent function apreq_escape.

Max

Re: obsolete functions?

[Joe Schaefer <jo...@sunstarsys.com>]

Max Kellermann <ma...@duempel.org> writes:

> Reading that code again, I rather think apreq_escape() can be dropped;
> there is no real advantage in using them, except for saving one
> apr_palloc() call. The same for apreq_unescape().

+1 to making apreq_escape and apreq_unescape inlined functions;
that way the aren't adding bloat to the library itself.  I'm -0 
on removing them entirely though.

-- 
Joe Schaefer

Re: obsolete functions?

[Max Kellermann <ma...@duempel.org>]

On 2005/02/06 18:03, Joe Schaefer <jo...@sunstarsys.com> wrote:
> > Why are both apreq_encode and apreq_escape exported?
> 
> I disagree; we should just document the 3*length+1 figure for
> apreq_encode.  It's useful to have an encoding function that isn't
> tied to a pool allocator. For example, the perl glue uses
> apreq_encode to write the result directly to a perl SV.  Replacing
> that with apreq_escape would just be a waste of resources.

ok. now what confuses me is the different name which says nothing
about the real difference between the two functions. Do you think it's
worth a rename?

apreq_escape returns a casted apreq_value_t*, which is not
documented. I guess this bit is obsolete now.

Reading that code again, I rather think apreq_escape() can be dropped;
there is no real advantage in using them, except for saving one
apr_palloc() call. The same for apreq_unescape().

Max

Re: obsolete functions?

[Joe Schaefer <jo...@sunstarsys.com>]

Max Kellermann <ma...@duempel.org> writes:

> I noticed the following functions, but couldn't explain their use in
> libapreq2:
>
>  apreq_quote
>  apreq_quote_once
>  apreq_memmem
>
> apreq_quote is used by apreq_join with APREQ_JOIN_QUOTE, but I do not
> see yet how this option helps apreq2. apreq_memmem is not used at all.

The quote functions are there mainly to give users a way to create
rfc-compliant cookie values and attributes.  For portability reasons
we can't enforce proper quoting in apreq_cookie_bake(2).  The best
we can do is provide functions that do "the right thing", and let 
our users take advantage of them when it makes sense for them to do 
it.

apreq_memmem is a relic from libapreq1;  I don't mind removing
it because apreq_index does basically the same job.

> Why are both apreq_encode and apreq_escape exported? apreq_encode is
> potentially unsafe - you need a 3*length+1 buffer in the worst case;
> this is not explicitly documented. We should only export the safe
> equivalent function apreq_escape.

I disagree; we should just document the 3*length+1 figure for 
apreq_encode.  It's useful to have an encoding function that
isn't tied to a pool allocator. For example, the perl glue 
uses apreq_encode to write the result directly to a perl SV.
Replacing that with apreq_escape would just be a waste of 
resources.

-- 
Joe Schaefer