Slashdot Mirror


Mac and iOS Bug Crashes Apps With a Single Indian-Language Character (mashable.com)

A lone Indian-language character is crashing a number of messaging apps on iOS, users are reporting. The problem also extends to the Apple Watch and even Macs, all of which struggle to process the character specific to the Telugu language spoken in India.

17 of 114 comments (clear)

  1. huh by cascadingstylesheet · · Score: 2, Funny

    And with all those Telugu-speaking programmers on staff too ... huh.

    1. Re:huh by cayenne8 · · Score: 4, Funny
      Geez.......

      And I thought it was bad enough trying to understand them on support calls......

      ;)

      --
      Light travels faster than sound. This is why some people appear bright until you hear them speak.........
    2. Re:huh by Anubis+IV · · Score: 4, Informative

      Ehh, the issue was fixed in the public betas before Mashable had even published their story about it.

      For a better writeup, check out MacRumors' reporting on it (which was published prior to Mashable's). They mention that the bug was reported to Apple on Monday and was fixed at some point between then and now, so Apple has had a pretty quick turnaround on this one. Even so, it remains to be seen whether these fixes will be published in a minor update prior to their next intended release, or whether we'll have to wait for iOS 11.3 and macOS 10.13.4 before we get the fixes, which would likely be next month.

      Meanwhile, Mashable's reporting is lagging. While they've found the time to update their article to indicate they finally managed to reproduce the issue, they apparently haven't had the time to update it with the fact that the bug was fixed before they ever wrote a word about it.

    3. Re:huh by Anubis+IV · · Score: 2

      Apple has now confirmed that the fixes they have in the public betas will be rolled out as minor releases for the current versions of iOS and macOS, rather than being kept for the next big release of each.

      As for Mashable's reporting? Still lousy. They finally updated their article with the information it was missing at the time it was originally published, but then they went and added that "the fix will slowly roll out to older software", suggesting that the current versions won't get the fix until after the betas are released, even though the iMore article they linked as a source for that info says nothing of the sort. Quite the contrary, iMore's editor-in-chief is saying Apple will roll the fixes out before the betas are released.

      Why is Slashdot using Mashable as a source when pretty much anyone else has more timely and accurate reporting, regardless of topic?

  2. plaintext FTW, eh? by cellocgw · · Score: 2, Interesting

    Right on the heels of the article and discussion of plaintext vs. rich text vs. whateverthefuck Google is about to unleash on email comes this screwup.
    I say it's high time that any and all text-ish messaging systems require just plain ASCII characters and if people insist on using alternative alphabets they dang well should be required to paste them in as images, not Unicode 84E0DDC2834A or however big the field is these days.

    --
    https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
    1. Re:plaintext FTW, eh? by frank_adrian314159 · · Score: 2

      I think if you have room for a picture of turds in your character set, you have been given too much space.

      --
      That is all.
    2. Re:plaintext FTW, eh? by Wycliffe · · Score: 2

      Right on the heels of the article and discussion of plaintext vs. rich text vs. whateverthefuck Google is about to unleash on email comes this screwup.
      I say it's high time that any and all text-ish messaging systems require just plain ASCII characters and if people insist on using alternative alphabets they dang well should be required to paste them in as images, not Unicode 84E0DDC2834A or however big the field is these days.

      I agree that the unicode emojis are ridiculous but plain ascii barely works for english let along other languages. You could map other languages onto english characters but even that presents a problem because many languages have more than 26 letters in their alphabet. A two byte character code either DBCS or unicode makes sense but any system that implements it should have a default for all 65k characters including the ones that it doesn't know how to display. The most common way I'm used to seeing it is a little box icon with the 4 digits crammed inside it but because many of those 65k characters are still undefined it should definitely not crash on an undefined character.

    3. Re:plaintext FTW, eh? by ShanghaiBill · · Score: 5, Insightful

      I say it's high time that any and all text-ish messaging systems require just plain ASCII characters

      Great idea. I totally agree that we should all adopt a single alphabet, but obviously the standard should be based on Chinese hanzi ideograms, not ASCII. Hanzi have a bigger user base, don't depend on a single spoken language, and are more compact since each character represents an entire syllable.

      If everyone is in agreement, we can start working on the unification immediately.

    4. Re:plaintext FTW, eh? by ghoul · · Score: 2

      As long as the standard characters are Telugu and you have to paste in English characters I am on board

      --
      **Life is too short to be serious**
    5. Re:plaintext FTW, eh? by TheFakeTimCook · · Score: 2

      There's nothing wrong with using either unicode or UTF8 in the 21st century, but if a particular subsystem isn't prepared to cope with input, it should reject any attempt to submit input it cannot properly handle. Even rendering unknown characters each in a small box with the unicode value written in it is an entirely reasonable coping mechanism. Rendering the wrong thing, or worse, crashing, is a result of either poor QA or lazy developers or both.

      Sez the person who has never coded a modern Operating System, that has to operate flawlessly WORLDWIDE, with a plethora of languages, fonts, even writing direction.

      And as I said earlier, Slashdot can't even handle an alternate "Quote" character without displaying gibberish. So I don't want to hear it...

  3. Re:A UTF8 processing failure? by Penguinisto · · Score: 2

    Solved 30 years ago? try 2017...

    --
    Quo usque tandem abutere, Nimbus, patientia nostra?
  4. Re:Sanitizing input is old fashioned by DickBreath · · Score: 2

    What programmers may already know how to do, and what managers allow them to spend time doing are two different things.

    Don't blame programmers when management is an adequate explanation for the problem. Managers are the cause of most problems in the world. They know this, and so they try to CYA on everything. It is because of their managers. It's managers all the way down, until you get into the infernal nether regions.

    And, they have the value hierarchy inverted. The "higher" up the org chart you go, the lower you are actually going down the value hierarchy.

    --

    I'll see your senator, and I'll raise you two judges.
  5. Re:See! It just works! by PolygamousRanchKid+ · · Score: 3, Funny

    Now, these kids today...one character.

    POOF!

    Note that this character was developed by the Indian military industry in a project with similar goals as the "Killer Joke": https://en.wikipedia.org/wiki/...

    The intent is that people reading the character die.

    Joke warfare is officially banned by the Geneva Convention, but India's archenemy Pakistan has been working on their own form of joke warfare involving a schoolgirl and a Nobel Peace Prize, and India felt threatened.

    --
    Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
  6. Re: A UTF8 processing failure? by Hal_Porter · · Score: 5, Informative

    A lot of embedded systems will behave strangely if you feed them a lot of characters like this

    https://en.wiktionary.org/wiki...
    http://www.unicode.org/cgi-bin...

    That character is four bytes in UTF-8 which kills systems that assume a maximum of three - which used to be true for Chinese and Japanese, but isn't now.

    It's also two UTF-16 code points, which will mess up systems that assume each character is a single code point.

    Now you'll say "Those systems are all buggy". That's true now, but it wasn't true when a lot of them were designed - Unicode used to be limited to 64K characters which meant it was a fixed width encoding for UCS-2. And that three bytes was the maximum encoding for UTF-8.

    When it grew those ceased to be true. Which is fine for systems that are maintained - the vendor would find bugs created by the standard change and push an update. Unfortunately a lot of systems - particularly embedded ones - aren't like that. Hell, Android isn't like that. Google push updates out to vendors but if your machine is EOL you're SOL.

    --
    echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
  7. Re:A UTF8 processing failure? by Hal_Porter · · Score: 2

    Android sucks for patching because it's all up to the vendors who don't care about old machines - they want you to buy a new device.

    However Apple sucks too - they force everyone to the latest version to get patches, and that version may run so slowly that you need to buy a new device.

    Actually Google have a clever idea called Project Treble to solve the update problem

    https://android-developers.goo...

    The idea is that there's a stable vendor interface to the low level parts so the stuff above that can be swapped out. Bad news is that it will only be in Android O and later. So it won't do anything to fix all the ageing Android devices out there as they slip out of vendor's support window.

    --
    echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
  8. Re: A UTF8 processing failure? by AmiMoJo · · Score: 4, Interesting

    Unicode is broken, and most Unicode apps are even more broken.

    It's time we replaced Unicode. Make 32 bits the only encoding. Ditch all combinational characters. Separate out all merged languages. Create some solid libraries to handle it an convert UTF8/16.

    With Unicode you can't even reliably tell how long a string is. Most software that claims to support it is buggy as hell. Programmers can't be expected to become language experts.

    --
    const int one = 65536; (Silvermoon, Texture.cs)
    SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  9. Re: A UTF8 processing failure? by Hal_Porter · · Score: 4, Funny

    We all need to adopt the Mojibake standard for non ASCII characters, like Slashdot.

    --
    echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;