Front page | perl.perl5.porters |
Postings from November 2008
Abigail wrote: > On Sat, Oct 25, 2008 at 07:23:29PM -0600, Tom Christiansen wrote: >> Dear Glenn and Karl, >> >> +=============================+ >> | SUMMARY of Exposition Below | >> v-----------------------------v >> >> * I fully agree there's a bug. >> >> * I believe Karl has produced a reasonable patch to fix it. >> >> * I wonder what *else* might/should also change in tandem >> with this estimable amendment so as to: >> >> ? avoid evoking or astonishing any hobgoblins of >> foolish inconsistency (ie: breaking bad expectations) >> >> ? what (if any?) backwards-compat story might need >> spinning (ie, breaking code, albeit cum credible Apologia) > > > I am seldomly in favour of new warnings for existing code, but perhaps > use of \NNN, with NNN > 377 in a regexp should trigger a warning, as > its behaviour is surprising - not to mention some code out there may > rely on the current (buggy) behaviour. > > > > Abigail > > So what's the answer? I don't think it should be an error for >=400. I think a warning would be ok, and I know enough to put such a warning into regcomp.c. And at compile time, one could handle >8-bit machines by testing sizeof(char). But what to do besides warn? Assume they meant unicode, as character classes do now, my patch would do? And I don't know the rest of the code. The only other place that grok_oct() is called is from the oct() function. My limited knowledge of how perl works suggests that a call to this is put on the stack when evaluating a double-quotish constant. I don't know enough about the code at this time to know how to add a warning to that. I think we're all agreed that there is a bug. And that there should be consistency of handling, unlike now. I await your responses.Thread Previous | Thread Next