incubator-triplesoup-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+apa...@sunstarsys.com>
Subject Re: libapreq2?
Date Thu, 03 May 2007 22:24:10 GMT
David Reid <david@jetnet.co.uk> writes:

>> For instance, it took quite a long time to work out
>> the bugs in httpd's header parsing facilities, mainly
>> because it's very easy for good programmers to take
>> a relatively simple task like that and optimize their
>> first crack at the code for simplicity and efficiency
>> over safety and correctness.  I took a brief look 
>> at mod_sparql's implementation and see some of the
>> same problems there.  It wouldn't be hard to fix
>> them, but I really believe we should use apreq's table
>> API instead.
>
> What problems? Be interested to see details...

In the current code, I see two problems:

1) mod_sparql is tokenizing after decoding, when what should
happen is the reverse.  Otherwise an encoded "&&" will
trip things up.

2) this code

                if (rawQuery)
                    rawQuery  = apr_pstrcat(r->pool, rawQuery, data, NULL);
                else
                    rawQuery = (char *)data;

is dangerous for two reasons: the allocator is quadratic (O(n^2)),
and data may be a freed pointer by the time it's used later in the code.
One way to fix the allocation issue, I think, is to use a doubling algorithm 
(always allocate twice the current length, and track how much is being
used), but I haven't tested it, and that's not what apreq actually uses.


-- 
Joe Schaefer

Mime
View raw message