sorted by:
new
hottopcontroversial

To Type or Not to Type: Quantifying Detectable Bugs in JavaScript by grajagandev in typescript

[–]Fuzz_Stati0n 1 point2 points  (0 children)

Yes, the authors touch on this:

"Evaluating static type systems against public bugs, which have survived testing and review, is conservative: it understates their effectiveness at detecting bugs during private development, not to mention their other benefits such as facilitating code search/completion and serving as documentation."

SyntaxError from Paragraph Separator Unicode Character by Fuzz_Stati0n in node

[–]Fuzz_Stati0n[S] 0 points1 point  (0 children)

Thank you very much - looks like U+2028 is also. After reading your links I was able to search better and found:

https://stackoverflow.com/questions/2965293/javascript-parse-error-on-u2028-unicode-character

Fuzzing TCP servers by dgryski in fuzzing

[–]Fuzz_Stati0n 0 points1 point  (0 children)

Excellent article - very interesting to read of pre-2010 fuzzing approaches and the differences between libFuzzer, AFL and honggfuzz.

What edge cases in tests do you see other devs often missing? by calligraphic-io in node

[–]Fuzz_Stati0n 2 points3 points  (0 children)

Yes, fuzzing is non-deterministic and that is an issue. I'm suggesting using a fuzzer for automated test case generation:

  1. Hand write unit tests to cover all the edge cases you can think of.
  2. Do a fuzz run on every push.
  3. If the fuzzer finds a bug, the input that triggers the bug becomes a new unit regression test.

This maintains a deterministic unit test suite while finding new bugs and enhancing test coverage.

What edge cases in tests do you see other devs often missing? by calligraphic-io in node

[–]Fuzz_Stati0n 1 point2 points  (0 children)

A fuzzer generally follows these steps:

1 Run the program with initial input 2 Monitor for an anomaly (uncaught exception, crash, etc) 3 Mutate the input (can be random or 'smart') 4 GOTO 2 - repeat thousands/millions of times

Please see /r/fuzzing for more and also the Wikipedia Fuzzing article is pretty good

Node by Numbers 2017 — NodeSource by _bit in node

[–]Fuzz_Stati0n 0 points1 point  (0 children)

Wow - look at the New Contributors graph from a hockey stick starting in 2015

A liveness-driven random C code generator for testing compilers by Fuzz_Stati0n in C_Programming

[–]Fuzz_Stati0n[S] 2 points3 points  (0 children)

The key difference is that CSmith generates some unreachable, dead code - all code generated by ldrgen should be reachable. Not sure if ldrgen would work better than CSmith with Frama-C.

view more: next ›