[llvm] [llvm-strings] Use small buffer instead of reading whole file (PR #163073)
Harald van Dijk via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 24 05:47:24 PDT 2026
================
@@ -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
----------------
hvdijk 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.
Indeed `printf` is not a built-in lit command. I saw it passing on my local system and it's also passing in CI so it's a bit surprising, but given that your `printf` is also behaving differently in other ways (per your other comment), perhaps there's some particular version that we need to take into account? Can you check where your `printf` is coming from? Mine is the version that comes with Git for Windows version 2.55.0.windows.3, and `printf --version` prints that the version is "printf (GNU coreutils) 8.32". I double-checked using Sysinternals Process Monitor that that was the version that was executed in the lit test.
> I fed this problem into ChatGPT and got the following useful-looking response and explanation
TBH, I'm not really happy pushing the limits of LLVM's already rather permissive (more permissive than I'm comfortable with) AI policy even further. It applies to comments on pull requests and the bar is higher than "useful-looking", so I would have preferred this not having been posted, personally. I'll disregard this, especially as I don't think everything in there is right and I don't want to argue with a bot.
https://github.com/llvm/llvm-project/pull/163073
More information about the llvm-commits
mailing list