Kostya Serebryany comments

Results 8 comments of


Kostya Serebryany

std::string_view encourages use-after-free; the Core Guidelines Checker doesn't complain

> calls this type StringPiece It's been renamed to `absl::string_view`. We've being finding *many* misuses of this class (causing heap-use-after-free and stack-use-after-return) since 2011. My POV is heavily biased due...

std::string_view encourages use-after-free; the Core Guidelines Checker doesn't complain

I haven't -- it's used everywhere, and when used carefully it brings lots of performance benefits. So, let me correct myself: it's a stability/security disaster and a performance win. tradeoffs...

std::string_view encourages use-after-free; the Core Guidelines Checker doesn't complain

And again, my complaint is not so much about `std::string_view`, but more about the core guidelines checker not reporting this and similar code as a problem (non-core).

std::string_view encourages use-after-free; the Core Guidelines Checker doesn't complain

> a proper static analysis tool Are you aware of any such tool? (and to make things more realistic, it should catch a general case, not just the patter where...

std::string_view encourages use-after-free; the Core Guidelines Checker doesn't complain

Making tools do something special for `std::string_view` or other hand-picked types is counter-productive, imho. Users will start to rely on checker to find misuses of `std::string_view` and won't realize that...

std::string_view encourages use-after-free; the Core Guidelines Checker doesn't complain

> Is it possible that assessment is too colored by frustration? It is colored by 6+ years of data-driven frustration. Here is [one of the recent discussions](http://lists.llvm.org/pipermail/cfe-dev/2017-June/054166.html ) that I...

std::string_view encourages use-after-free; the Core Guidelines Checker doesn't complain

> "correct" usage of std::string_view is not defined by its implementation anyway, but by it's specification (the standard). @MikeGitb, well, ok, agree. If we catch this and other common cases...

make fuzzing a first class citizen in Go

I would advocate for a slightly different order: * define the fuzz target API * write a few micro fuzz targets using that API (similar to [libFuzzer's tests](https://github.com/llvm-mirror/compiler-rt/tree/master/test/fuzzer) * write...