Funny that you bring this up... I'm been tracking down some bugs and they all seem to be XML related... fastsax->libwriterfilter with occasional cores due to __cxa_call_unexpected.
I feel that making AOO more fragile by trying to work around cases where invalid and/or non-compliant XML is encountered is just wrong. We should either ignore the error (catch it) or raise an exception. Invalid data shouldn't be tolerated. Additionally, trying to be "lenient" is an easy vector for vulnerabilities. My 2c > On Feb 3, 2021, at 1:38 PM, Arrigo Marchiori <ard...@yahoo.it.INVALID> wrote: > > Dear List, > > bug 128356 [1] is mostly about an XML tag that carries an attribute > _twice_. This is not allowed; the SAX parser raises an exception when > it finds it while loading the file, and the user gets upset because > they cannot open their file any more. > > While I am looking for the actual cause of this bug, I think it may be > useful to stop this XML error from happening anywhere. Our API should > complain heavily when requested to do such an illegal action. > > I am going to add a ``safety-check'' into the methods of class > SvXMLAttributeList to avoid ``adding'' an attribute that is already in > the list. But what shall these methods do instead, apart from > complaining? > > 1- just ignore the request, leaving the current value for the > attribute; > > 2- set the new value, overwriting the current one; > > 3- raise an exception because it is just not acceptable. > > I personally like option 3-, but someone may have a different opinion? > > In addition to this, when finished with the bug, I will try to make > the SAX parser accept these duplicated attributes, and try to carry on > loading the file. This should help our angry users recover their data, > even if some information may be lost. > > Please share your opinion. > > References: > 1: https://bz.apache.org/ooo/show_bug.cgi?id=128356 > > Best regards, > -- > Arrigo > > http://rigo.altervista.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
