[llvm] [llvm-strings] Use small buffer instead of reading whole file (PR #163073)

[James Henderson via llvm-commits]

================
@@ -51,57 +43,28 @@
 ## before the chunk start and one after its end. The string is printed
 ## intact, once. The expected output is generated rather than written as a
 ## CHECK line because it is a chunk long.
-# RUN: %python %s 16383 S M at 16384 E 4 > %t.6
-# RUN: %python %s --line S M at 16384 E > %t.6.expected
+# RUN: printf "%16383sS%.16384dE%4s" | tr " " "\0" > %t.6
+# RUN: printf "S%.16384dE\n" > %t.6.expected
----------------
jh7370 wrote:

Unfortunately, this is failing for me locally. It looks likely to be the fault of the redirection to file, and lit presumably is doing it in text mode, at least under some conditions, since printf is presumably not a built-in lit command. I checked and the expected file ends with \r\n. I fully expect there to be similar problems in the later tests that do a similar thing too.

I fed this problem into ChatGPT and got the following useful-looking response and explanation, so I figured it would be useful sharing. Caveat: I've tested the fix and it doesn't seem to produce an expected file that is of the same size as the old code nor have I verified the full explanation (it does sound familiar though).

> On Windows, the `\r` is being introduced by **text-mode output translation**, not by the `printf` format string. `\n` written through a Windows text-mode stream becomes `\r\n`. LLVM itself has code that explicitly switches output to binary mode on Windows when LF must be preserved, for exactly this reason.
>
> For a lit test, I’d avoid `printf` for this and use `%python` to write the file in **binary mode**:
>
>```text
> # RUN: %python -c "open(r'%t.6.expected', 'wb').write(b'S' + b'0' * 16384 + b'E\n')"
> ```
>
>That produces exactly:
>
>```text
>S
><16384 zeroes>
>E\n
>```
>with the final byte being `0x0a`, even on Windows.
>
>This is preferable to trying something like:
>
>```text
>printf "S%.16384dE\n" | ...
>```
>
>because any native Windows utility in that pipeline can potentially put its stdout into text mode and reintroduce CRLF translation.
>
>Also, lit's redirection handling on Windows has historically opened `>` targets as text streams. Current lit code has machinery to bypass text-mode translation for some in-process builtins, but an external `printf` is still a separate process and its own stdout mode matters. 
>
>If you want to retain the `printf` expression specifically, another robust variant is to let Python post-process its output as bytes, but that's more complicated than necessary here. For this test data, the explicit binary Python write is probably the clearest and most portable LLVM-test idiom.

https://github.com/llvm/llvm-project/pull/163073