On Sat, 9 Feb 2008, Ruediger Pluem wrote:
> > + return apr_table_make(pool, 10);
> > + };
> > +
>
> Why this? Just some type of defensive programming if someone feeds in a t ==
> NULL?
> If yes, I would prefer return NULL instead of creating an empty table.
> Garbage in, garbage out :-).
That was my first approach as well. But then I noticed that the users of
this functions virtually always will have to serialize/store the tables;
or otherwise track them. So if we have 3 options -
- if (r->headers_in)
in = ap_cache_cacheable_hdrs_in(
serialize(in)
else
mark a skip or something that you did not
- headers_in = ap_cache_cacheable_hdrs_in(
if (headers_in)
serialize(in)
else
mark a skip etc
- headers_in = ap_cache_cacheable_hdrs_in
serialize(headers_in) which can deal with empty arrays
or we defer - and simply return null and have the respective serializes
all deal with this. The advantage of returning null is that it is quicker
to check for those serializers. But if I had to optimize - I'd rather do
so on assuming an array - as in reality we have the headers virtually
always ?
> How about using @deprecated here instead of warning?
..
> Style ...
Will fix prior to commit.
Dw.
