[libc-commits] [PATCH] D74091: [libc] Lay out framework for fuzzing libc functions.

[Alex Brachet via Phabricator via libc-commits]

abrachet added inline comments.


================
Comment at: libc/fuzzing/string/strcpy_fuzz.cpp:16
+  size_t i;
+  for (i = 0; src[i] != '\0'; i++){
+    // ensure correctness of strcpy
----------------
PaulkaToast wrote:
> abrachet wrote:
> > Couldn't this just be from i = 0 to size?
> The length of the string that strcpy copies may not be the same as the size of the fuzzing input due to null-terminators appearing at random in data.
Then if it is completely random this `if (data[size - 1] != '\0') return 0;` will end the test 255/256 times, no?

Also without removing the 0's like before from the input then the average length will be just 256 then. Is this a problem? Or perhaps a better question is it a smaller problem than the previously raised concerned that the extra allocation was too costly?


================
Comment at: libc/fuzzing/string/strcpy_fuzz.cpp:22
+  char *dest = new char[size];
+  if (!dest) __builtin_trap();
+
----------------
Should we be failing when the system can't allocate memory this isn't `__llvm_libc::strcpy`'s fault.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74091