djm03178's blog

fread's behavior with line breaks
By djm03178, 11 days ago, In English

UPD: I suppose that this is NOT the tests' fault. See https://codeforces.net/blog/entry/137318?#comment-1228025 .

To be short, I think it goes like this:

  • fread reads all characters from the test, write them into the destination array.
  • fread looks for "\r\n"s (or just "\r", idk), and remove '\r' from the array. Each of its occurence shifts the remaining part of the array to the left.
  • As a result, the final data gets shorter than the actual bytes it read from the file. However, it does not clear out the part after the shortened data. It returns the length of the shortened data, but if we check the data after it, we can see the leftovers.

I can't find anything stating that fread is supposed to remove '\r's from the reference, and it just feels really weird, but I guess this behavior's reason is explained at least.

Searching further, I found that stdin is by default opened as text mode, and in that context fread can really truncate '\r's to let users handle texts more conveniently, so all of this seems to be explained now.

Please, ignore the rest of the blog.

Old content, don't read
  • Vote: I like it
  • +29
  • Vote: I do not like it

»
11 days ago, # |
  Vote: I like it 0 Vote: I do not like it

EOL in testlib is platform dependent: https://github.com/MikeMirzayanov/testlib?tab=readme-ov-file#validator

→ Reply
  • »
    »
    11 days ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    Then it's rather strange that we also have just '\n' in the tests, isn't it?

    → Reply
    • »
      »
      »
      11 days ago, # ^ |
      ← Rev. 2   Vote: I like it 0 Vote: I do not like it

      Yeah looks a testlib validator really expects a CR if on windows. The problem author probably used a non-standard validator or skips the validation.

      → Reply
      • »
        »
        »
        »
        11 days ago, # ^ |
          Vote: I like it 0 Vote: I do not like it

        I'm investigating more about this, and here's what I found out:

        • The "actual test" part, actually ends at the 108th character. 296760620. It was due to my code's bug that tried to read further. However, this means that all characters in the "actual test" part has no CR; they only have LF.
        • For whatever reason, fread returned 108 correctly, but the loop next to it shows that it actually read more than that, and it does have CR.
        • So the only conclusion I can make is, that fread actually first read the test with the CR, and that ended up with having more characters. After that, it probably truncated the data by itself, removing all CRs from it, but did not clear out the written data after the k-th character.

        So I suppose the tests are correct (they all have CR), but it's fread's weird functionality that left unusable characters after the final data.

        → Reply
»
9 days ago, # |
  Vote: I like it +12 Vote: I do not like it

Codeforces uses Windows. And stdin is a text stream by default. On Windows when data is read from text stream all \r\n are converted to \n automatically.

You may see what fread does on Windows and Remarks in particular on the official site https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fread?view=msvc-170#remarks . The behaviour is expected.

→ Reply