On 11/29/2010 1:35 AM, Nicholas Clark wrote: > On Sun, Nov 28, 2010 at 02:36:22PM -0800, Reverend Chip wrote: >> On 11/28/2010 2:31 PM, Nicholas Clark wrote: >>> On Sun, Nov 28, 2010 at 02:26:51PM -0800, Reverend Chip wrote: >>>> On 11/28/2010 2:34 AM, demerphq wrote: >>>>> However if it means we have to validate the string every time we do a >>>>> utf8 operation then I would say you are wrong. >>>> Slippery slope fallacy. >>> Why so? >> Because "validate" implies a level of caution that I have never >> requested, and never will. At most I've requested "don't actually >> crash" with a side order of "show me where I need to add protective >> calls to utf8::validate", which would be satisfied by, for example, >> avoiding invalid C pointers caused by bad utf8 and turning any >> invalid-utf8-caused asserts to croaks. As you well know, avoiding > Yes, which means that you are requesting that we either > > a: audit the code for every possibility of this happening > > or > > b: effectively play whack-a-mole by treating every instance of discovering > that perl is crashing due to users using functions marked [INTERNAL] to > produce invalid internal state as a core bug that needs fixing. I still don't consider "validation" a fair label for either approach, but obviously it would set a precedent you find unacceptable. I'm quite disappointed in where this has taken us; apparently _utf8_on() will continue to be capable of crashing Perl. So it comes down to the documentation not carrying any warning labels saying "MAY CRASH PERL".Thread Previous | Thread Next