[PATCH] D83834: Add test utility 'split-file'

[James Henderson via Phabricator via llvm-commits]

jhenderson accepted this revision.
jhenderson added a comment.

LGTM, with or without the suggestion, but since others had comments about this, it would be good to get another pair of eyes to give it another look over.



================
Comment at: llvm/tools/split-file/split-file.cpp:126
+    Part &part = keyValue.second;
+    for (int i = 0; i != part.leadingLines; ++i)
+      (*f).os().write('\n');
----------------
Another possible `int64_t` site.


================
Comment at: llvm/tools/split-file/split-file.cpp:63
+  const char *end = nullptr;
+  int leadingLines = 0;
+};
----------------
MaskRay wrote:
> jhenderson wrote:
> > Whilst it's probably harmless, I don't think this should be an `int` (and similar comments for other liner number variables, e.g. `lineNo` in `handle`), since it can never be negative. `size_t` or possibly `unsigned` seem more appropriate for the context.
> Emm. I think it is debatable whether `undefined` is a suitable type here. See comments starting from https://reviews.llvm.org/D82594#2127217 for some discussions.
> 
> I actually perform arithmetic near zero below (`i.line_number() - 1`). int gives me more confidence that things don't go off.
It turns out that `line_number` is an `int64_t`. So I drop my point about `unsigned` or `size_t` (at least for this case, but I'm hardly convinced on the general case discussed on that or previous threads). However, perhaps `leadingLines` etc should be `int64_t` to match and avoid any truncation issues (noting in particular that the value could be anything in the range due to how EOF is handled)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83834/new/

https://reviews.llvm.org/D83834