Re: Checking string allocations (was Re: String literals, ASCII vs UTF-8)

On 02/29/2012 03:28 PM, Lubos Lunak wrote:
> On Wednesday 29 of February 2012, Stephan Bergmann wrote:
> > However, there are also situations where bad input (malicious or
> > otherwise) would cause an application to request excessive amounts of
> > memory to do a single task (e.g., open a document), and at least in
> > theory the application should be able to cope with such
> > externally-induced OOM conditions, by abandoning the bad operation,
> > cleaning up after it, telling the user the operation failed, and
> > carrying on.
>
>   The problem with this theory is that it is a theory. In practice the code
> should check the size first, and if it doesn't, then it presumably will not
> clean up properly anyway.

But checking the size beforehand is not trivial.  Where exactly to draw 
the line between legitimate but large allocation requests and bogus 
ones?  What about cases where the allocation is not in one big chunk, 
but piecemeal (say, ending up in a linked list) with an excessive number 
of innocently-looking small allocations?

>   The other problem is that OUString ctors is just one random place. The
> OUStringBuffer ctor, which is probably a more likely place to first hit the
> problem if the input handling itself is sloppy and lets the problem get past,
> does not bother with any such checks. So what we have now is a half-solution
> that is not likely to work anyway. Either we want this done properly, in
> which case input should be validated. Or we want it with less work but still
> reasonably safe, in which case all the C rtl_ustr_* functions should detect
> this and abort. Either case does not really need it in OUString ctors.

We want it done properly, I'd say (and think the sloppy code should be 
fixed -- in theory at least; there are always more pressing problems 
with the code), but I do not buy your "done properly" => "input should 
be validated [and checking for OOM in OUString ctor etc. becomes 
unnecessary]" implication (see above).

Stephan