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

[Paula Toth via Phabricator via libc-commits]

PaulkaToast marked an inline comment as done.
PaulkaToast 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
----------------
abrachet wrote:
> 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?
Apologies, it wouldn't be completely random, the fuzzer is coverage guided so it'll learn that null-terminated strings are what we expect and it should then provide that more often. This was explained to me offline and it seems that modifying the input isn't necessarily needed and we should leave it up to the fuzzer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74091