<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> I would expect that filters should be validating their inputs. By the time that we get a bad_alloc, it's too late to recover properly. Unless we're talking about someday running filters in a separate process, and then validating the document they generate, in which case the main process would remain safe. On 2012-02-29 15:48, Eike Rathke wrote: <blockquote cite="mid:20120229134828.GA12233@isigqoko.erack.de" type="cite"> <pre wrap="">Hi Stephan, On Wednesday, 2012-02-29 08:42:35 +0100, Stephan Bergmann wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> I think catching std::bad_alloc and returning an error should be possible in most filter code based on SfxObjectShell / SfxMedium. Eike </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ LibreOffice mailing list <a class="moz-txt-link-abbreviated" href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/libreoffice">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a> </pre> </blockquote> <hr>Disclaimer: <a href="http://www.peralex.com/disclaimer.html">http://www.peralex.com/disclaimer.html</a> </body> </html>