4 ms·

Can anyone explain why this crash editors?

• homemadejam 9y ago
  Opening this file in a hex editor shows that the file consists of almost all spaces, which I'm assuming are all on one line, making the text editors crash.
  • icebraining 9y ago
    Yeah, hexdump shows: 00000000 ef bb bf 2f 3e c2 a0 0a 20 20 20 20 20 20 20 20 00000010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 * 00900000 20 20 20 20 20 20 20 20 3c 61 0090000a Which means that except for those first 8 bytes and the last two, the whole file is just 0x20 (space in ASCII/UTF-8) repeated ad nauseam.
    • gnator 9y ago
      Why would long lines crash editors?
      • pwg 9y ago
        If the editor has some built in line length limit then exceeding that limit might lead to a crash (depending upon how the editor is coded).
        • gnator 9y ago
          Right but it looks like (i was able to load it for Atom and Notepad++ but very slow) they perform soft wrap on these long lines
          • pwg 9y ago
            Which would imply that their soft-wrap algorithm consumes an inordinate amount of time when confronted with a single, 9MB long, line of space characters.
      • icebraining 9y ago
        Well, VIM doesn't crash :) But edge cases in general are where the bugs lurk, and 9MBs of spaces is certainly an edge case. A possible cause might be that they try to render the whole line, try to allocate too much memory, and crash when the allocation fails. Whereas if the file had many lines, they'd probably be smart enough to only render part of it.
• pwg 9y ago
  The file opens in a blink of an eye on Linux in both the Joe editor (http://joe-editor.sourceforge.net/ http://joe-editor.sourceforge.net/) as well as in vi (i.e., it is about about a second or less to open the file in each). So the problem would be that Word, Notepad++, and Atom have trouble with very long lines.
• db48x 9y ago
  You just need a better editor; it doesn't crash Emacs, for example.