3 ms·

This is just a work around for: a) A lack of strong typing b) A custom compiler toolchain llvm already has instrumentation/ coverage support and generics mak

This is just a work around for: a) A lack of strong typing b) A custom compiler toolchain llvm already has instrumentation/ coverage support and generics make it easy to work with higher level constructs than bytes, although you generally do want to just work with bytes when fuzzing imo. The language is weak, therefor the language has to add more and more batteries-included because extending it is purposefully difficult.

masklinn 5y ago
> This is just a work around for: > [...] > llvm already has instrumentation/ coverage support I mean, that supports the idea of having fuzzing support in whatever core you have.
- staticassertion 5y ago
  My point is that between Go's custom compiler backend and inexpressive typing there's much more need to build things like this in directly vs what other languages can do by just using llvm/gcc. Like if Go developers want sanitizers equivalent to what llvm packages they'll have to build that themselves, although that won't have the same issue with inexpressive types.
  - aleksi 5y ago
    > Like if Go developers want sanitizers equivalent to what llvm packages they'll have to build that themselves Go uses LLVM’s ThreadSanitizer since 1.1.
    - staticassertion 5y ago
      I don't think that really addresses my point, it just shows that they did the work for one sanitizer already.
smasher164 5y ago
> llvm already has instrumentation The Go toolchain actually supports emitting instrumentation for LLVM's libFuzzer with -gcflags=all=-d=libfuzzer. > therefor the language has to add more Okay, and so? If this ends up making fuzzing more popular and easy-to-use, I frankly don't care if it was added as a library or deeply integrated into the toolchain.
- staticassertion 5y ago
  > The Go toolchain actually supports emitting instrumentation for LLVM's libFuzzer with -gcflags=all=-d=libfuzzer. Sweet, that's a smart approach. > Okay, and so? If this ends up making fuzzing more popular and easy-to-use, I frankly don't care if it was added as a library or deeply integrated into the toolchain. I don't care either because I don't write Go, so just the fact that it's supported is nice for me since it encourages this in languages I do care about. But if I were a go developer I might care a lot about how my language evolves, what's built in, what's a library, what the capabilities are, what tools I can integrate with, etc. It sounds like they've done a pretty good job with regards to this implementation though, happy to see it.

masklinn 5y ago

> This is just a work around for: > [...] > llvm already has instrumentation/ coverage support I mean, that supports the idea of having fuzzing support in whatever core you have.

staticassertion 5y ago
My point is that between Go's custom compiler backend and inexpressive typing there's much more need to build things like this in directly vs what other languages can do by just using llvm/gcc. Like if Go developers want sanitizers equivalent to what llvm packages they'll have to build that themselves, although that won't have the same issue with inexpressive types.
- aleksi 5y ago
  > Like if Go developers want sanitizers equivalent to what llvm packages they'll have to build that themselves Go uses LLVM’s ThreadSanitizer since 1.1.
  - staticassertion 5y ago
    I don't think that really addresses my point, it just shows that they did the work for one sanitizer already.

smasher164 5y ago

> llvm already has instrumentation The Go toolchain actually supports emitting instrumentation for LLVM's libFuzzer with -gcflags=all=-d=libfuzzer. > therefor the language has to add more Okay, and so? If this ends up making fuzzing more popular and easy-to-use, I frankly don't care if it was added as a library or deeply integrated into the toolchain.

staticassertion 5y ago
> The Go toolchain actually supports emitting instrumentation for LLVM's libFuzzer with -gcflags=all=-d=libfuzzer. Sweet, that's a smart approach. > Okay, and so? If this ends up making fuzzing more popular and easy-to-use, I frankly don't care if it was added as a library or deeply integrated into the toolchain. I don't care either because I don't write Go, so just the fact that it's supported is nice for me since it encourages this in languages I do care about. But if I were a go developer I might care a lot about how my language evolves, what's built in, what's a library, what the capabilities are, what tools I can integrate with, etc. It sounds like they've done a pretty good job with regards to this implementation though, happy to see it.