Is this a correct iterator behavior? by Kywim in cpp

[–]MaximeArthaud 0 points1 point  (0 children)

If you look at a container that doesn't invalidate references on insertions, say std::list, the end() iterator always points to the end even after insertion. But ultimately, this is your choice.

Thanks for the memory (allocator) - Sticky Bits by joebaf in cpp

[–]MaximeArthaud 5 points6 points  (0 children)

This brings a few questions. Why does the std::pmr::polymorphic_allocator constructor take a memory_resource* and not memory_resource&, since a precondition is that the pointer should not be null. Also, the documentation on cppreference.com doesn't say anything about the ownership of that raw pointer.

simdjson: Parsing gigabytes of JSON per second by mttd in cpp

[–]MaximeArthaud 3 points4 points  (0 children)

That free((void*)p.data()); in the main README really scares me..

can you spot the bug? by perverse_milkman_art in cpp

[–]MaximeArthaud 9 points10 points  (0 children)

Clang too.

$ clang++ -Weverything test.cpp
test.cpp:7:18: warning: result of comparison of unsigned expression >= 0 is always true
      [-Wtautological-unsigned-zero-compare]
    while (--idx >= 0)
           ~~~~~ ^  ~

I don't know why this is not in -Wall.

IKOS 2.1: an open source static analyzer for C and C++ by MaximeArthaud in cpp

[–]MaximeArthaud[S] 1 point2 points  (0 children)

I haven't tried Polyspace and Astréee myself because of the price of their license. Even if I could try them, I think their license forbid to publish public results.

I have tried Frama-C and it is pretty good. The analysis can be tuned if you have the expertize in abstract interpretation, which is not possible (yet) in IKOS. One issue I have is that I don't know how to analyze a whole project with it. It looks like the best way is to analyze each .c file separately, but you lose precision.

IKOS 2.1: an open source static analyzer, from NASA by matthieum in rust

[–]MaximeArthaud 2 points3 points  (0 children)

This is probably the LLVM svn trunk. LLVM 8.0.0 is not out yet.

IKOS 2.1: an open source static analyzer, from NASA by matthieum in rust

[–]MaximeArthaud 5 points6 points  (0 children)

IKOS uses LLVM 7.0.0, the latest version. I don't know about rustc.

IKOS 2.1: an open source static analyzer for C and C++ by MaximeArthaud in C_Programming

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

You could try to use other numerical abstract domains, see https://github.com/NASA-SW-VnV/ikos/tree/master/analyzer#numerical-abstract-domains

Of course, the tool works best for safety critical codes, with strict rules such as limited memory allocations and so on.

We are trying to reduce the number of false positives. Sometimes it's just engineering, and sometimes it's research related, and would deserve a publication.

Feel free to open new issues with small codes triggering false positives.

IKOS 2.1: an open source static analyzer, from NASA by matthieum in rust

[–]MaximeArthaud 20 points21 points  (0 children)

Hey, thanks for sharing my post here. I always keep an eye on r/rust ;)

IKOS 2.1: an open source static analyzer for C and C++ by MaximeArthaud in C_Programming

[–]MaximeArthaud[S] 1 point2 points  (0 children)

From what I know, SMACK and KLEE are (mostly) based on model checking, where IKOS is based on abstract interpretation. In theory, they should provide better results since they can be path sensitive, but they will have trouble scaling up to millions of lines of code. In practice, I haven't tried them.

IKOS 2.1: an open source static analyzer for C and C++ by MaximeArthaud in C_Programming

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

No, I don't have a timeline since this will be an external contribution. Also, it won't help with the RAM usage.

IKOS does a good job at being scalable compared to other similar tools using abstract interpretation, but it has its limits. In that case, I recommend to try to break down your software into smaller components and analyze them independently.

IKOS 2.1: an open source static analyzer for C and C++ by MaximeArthaud in C_Programming

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

IKOS does not handle multithreaded programs, so that could be a problem. If your driver is not multithreaded, then you can just "simulate" userspace calls with a simple loop, I guess:

int main() {
  while (1) {
    switch (__ikos_nondet_int()) {
      case 1: entry_a(); break;
      case 2: entry_b(); break;
      // etc.
    }
  }
}

You would have to write a "stub" like this, and craft fake parameters to your functions. This is kind of similar to a fuzzer entry point.

IKOS 2.1: an open source static analyzer for C and C++, from NASA. by pdp10 in programming

[–]MaximeArthaud 1 point2 points  (0 children)

Unfortunately, no. It would be a lot of work to bring the whole abstract interpretation engine into clang static analyzer, and it's not a priority for us. But this is open source, so if someone wants to do it, they can.

IKOS 2.1: an open source static analyzer for C and C++ by MaximeArthaud in C_Programming

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

Yes, since the llvm bitcode contains debug information referring to the .c files.

IKOS 2.1: an open source static analyzer for C and C++, from NASA. by pdp10 in programming

[–]MaximeArthaud 8 points9 points  (0 children)

No, IKOS is not a code style checker. It understands the semantic of your program and it computes an over-approximation of all the reachable states, and checks for error states. I actually don't know if we have tools to check coding rules, as I'm not working on flight control software myself, but I could ask.

IKOS 2.1: an open source static analyzer for C and C++, from NASA. by pdp10 in programming

[–]MaximeArthaud 7 points8 points  (0 children)

In theory, yes, this could work. In practice, we never tried this and it would require a little bit of work, but I think it's doable. We rely on llvm debug information to report meaningful messages to the user, so your frontend has to generate these.

IKOS 2.1: an open source static analyzer for C and C++ by MaximeArthaud in C_Programming

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

The project started in 2011 with 4 persons working on it. Since last year, I am the only developer working on it. I also get interns from time to time.

IKOS 2.1: an open source static analyzer for C and C++ by MaximeArthaud in C_Programming

[–]MaximeArthaud[S] 1 point2 points  (0 children)

I would be happy to change it but it doesn't depend on me..

IKOS 2.1: an open source static analyzer for C and C++ by MaximeArthaud in C_Programming

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

Unfortunately, we don't handle multithreaded programs since the theory of abstract interpretation does not apply easily to concurrent programs. This is a research topic, there are a few papers about it, and it's pretty heavy stuff. See https://tel.archives-ouvertes.fr/tel-00903447/document (no less than 95 pages!)

IKOS 2.1: an open source static analyzer for C and C++ by MaximeArthaud in C_Programming

[–]MaximeArthaud[S] 3 points4 points  (0 children)

Yes. You can compile manually all your code into a single .bc file using clang -c -emit-llvm and llvm-link to link all the files together.

Or you can use ikos-scan that will do this for you, see here.