On 02/09/2008 08:39 PM, Dirk-Willem van Gulik wrote:
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 ?
This is my thought. I currently see no situation where we supply a NULL
to ap_cache_cacheable_hdrs now or in the future (in most cases I would assume
not even an empty table). So I think returning NULL in ap_cache_cacheable_hdrs
in this situation and write the serializer in a way that it can handle a NULL
table gracefully seems to be a quick and sufficient measure here to avoid
segfaults.
So I would vote for option 3.
Regards
Rüdiger
