Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re^3: Fatal code point 0xFFFFFFFFFFFFFFFF

by Anonymous Monk
on Sep 09, 2018 at 12:43 UTC ( #1221976=note: print w/replies, xml ) Need Help??


in reply to Re^2: Fatal code point 0xFFFFFFFFFFFFFFFF
in thread Fatal code point 0xFFFFFFFFFFFFFFFF

Thanks man but I hate the Encode docs. They can't give one lousy example on the exact syntax of CHECK to suppress unicode's stupid errors. Anyway I tried shoving ,Encode::FB_QUIET in there and it seems to work at turning off the noise. But as usual the docs are not so clear and seem to say that FB_QUIET stops decoding at the error and returns undecoded data? Really not useful. Is just sending Unicode's useless fatals to devnull an effective way to deal with data I just don't care too much about being exactly and perfectly correct according to the commandments of the freakin unicode consortium? Practical extraction of text used to be so easy, now it's calculus :-/

Thank you for your help

Replies are listed 'Best First'.
Re^4: Fatal code point 0xFFFFFFFFFFFFFFFF
by dave_the_m (Monsignor) on Sep 09, 2018 at 13:24 UTC
    to suppress unicode's stupid errors.
    They are not stupid errors. The errors (in fact warnings - they only become errors from 5.28 onwards) are telling you that you are trying to feed illegal data into the regex engine. It's illegal because the octets you told decode() to interpret as utf8 aren't in fact valid utf8.

    How you want to handle this corrupt data is of course your choice depending on what is best for your circumstances. You might want to make decode croak if fed a bad file with FB_CROAK, then go back and delete / fixup any bad files. Or depending on the nature of the corruption of the files, you might like to use FB_DEFAULT to just replace the corrupt bits with REPLACEMENT CHARACTER. You would only want to use FB_QUIET if you don't mind decode() stopping at the first bad part of the file and ignoring the rest of its contents.

    Dave.

      Thanks again Dave. I can't believe Perl is gonna die just because of "illegal" unicodes in the regex engine. PERL HAS A LICENSE TO ILL! Why don't they just warn and continue? Or do something mellow like ignore illegal code points, or just change uncool values to the max (and give weenies strict for unicode if they require torture)? Why be Unicode Security Guards? All these negative vibes while parsing something as important as 21st century text can't possibly be right for Perl:
      
      deprecated
      permissible
      fatal
      will not be allowed
      it is too large
      break the perl
      causing it to hang
      problem areas
      breakages
      warning
      upper limit
      out of range
      was deprecated
      a fatal error
      Perl 5.28
      
      
      That's from one error message. I don't know who wrote that but they do not sound like a happy camper! Let's send them some love so they can transform all that dark energy into something wonderful, like this:

      Use of code point 0xFFFFFFFFFFFFFFFF detected; but the permissible max is 0x7FFFFFFFFFFFFFFF. Perl can handle this at X.pm line 1685

      (D dude!) You used a code point that is way too large. Unicode only allows code points up to 0x10FFFF, but of course Perl allows much larger ones. However, the perl interpreter can handle anything. So your error has been automagically corrected! If your code is to run on various platforms, keep in mind that the upper limit depends on the platform. It is much larger on 64-bit word sizes than 32-bit ones.

      The use of out of range code points was acceptable in Perl 5.24, and it will be totally cool, but still pointless, in Perl 5.28.

        I can't believe Perl is gonna die just because of "illegal" unicodes in the regex engine
        In the past the perl interpreter would often crash or leave itself open to security holes when fed badly-formed utf8. Now it more often detects such cases early and refuses to continue (with just warning for a grace period to allow people to fix up their code).

        There are 7,389 lines in the main perl interpreter C source which have the the text 'utf' in them. If you want to volunteer to do a thorough audit of every single one of those lines to look for, e.g. negative wrap-around, performance degradation and security issues, and want to write comprehensive tests for every case, for both 32-bit and 64-bit platforms, then its possible that the decision to ban code-points above 2^(N-1) might be rescinded.

        But there really is no point. If you're feeding codepoints > 0x7fffffffffffffff into perl, something fairly major has gone wrong, and quietly ignoring those rogue codepoints is just masking the bigger issue.

        Dave.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1221976]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (3)
As of 2019-06-19 03:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Is there a future for codeless software?



    Results (83 votes). Check out past polls.

    Notices?
    • (Sep 10, 2018 at 22:53 UTC) Welcome new users!