CODEWITHSUNDEEP
c++undefined-behavior
user5528169
user5528169

Reputation:

Deal with project which may contain undefined behaviour

I would like advice how to proceed in such situation. Imagine I have large C++ project which works well.

I have suspicion there might be some UB in this code (because in different project written by same author I found UB).

Now, say I need to add new features to this project. I am afraid because:

Is it realistic to eliminate all UB in this large project by eye inspection (before I move to adding new feature)??

If not, then I should at least compile with same version of compiler right? (to decrease chance of problems if there is UB).

Project is done in Visual Studio so I don't know if there are object files, in which case, I could leave object files same and only modify parts in files where I need to add something - thus again minimizing risk of UB.

What is the course of action in such situation? I think this could be pretty common scenario.

I like suggestion that I test the project using new compiler before adding new code, but even then - we know testing might not reveal UB, isn't it?

Upvotes: 2

Views: 204

Answers (3)

MikeMB
MikeMB

Reputation: 21156

As others said: First and foremost, try to find the errors, not hide them.

  1. The first and simplest measure is to set the warning level to /W4 (you can try Wall, but due to the large amount of noise this will produce (e.g. from standard headerfiles), it is usually only of help if you know you have an error in a certain part of your code)
  2. Use static analyzers - you can start with the builtin Code Analysis tool and then go for external tools (which are usually much more difficult to set up correctly for a non-trivial project).
  3. Write lots of tests and make sure, you are exercising edge cases - thats where UB usually lurks.
  4. If possible, try to compile the project (or parts of it) under clang and activate the different sanitizers (in particular there is UndefinedBehaviorSanitizer) which will further instrument your code to check for UB (only helpfull if you have tests to exercise that UB though)
  5. Test your code at different optimization levels and combination of flags (in VS, especially _ITERATOR_DEBUG_LEVEL can be helpfull to find out-of-bounds errors)

I'd say any non-trivial code base potentially contains undefined behavior. What is special about that particular Programmer? If he/she is prone to a special kind of UB, then you can focus your efforts on this.

Upvotes: 2

user23573
user23573

Reputation: 2569

Undefined Behavior = Bugs

It's impossible to prove that a project is bug-free. Even the best programmers do create bugs. Even the best code-review cannot eliminate all bugs in a project. No, it's not realistic to eliminate all UB in a project of some size by code inspection or by any other means. Your best option is to review the code and eliminate as many as possible.

  • Change your perception of UB (bugs): If you encounter a bug during your re-engineering efforts, it's a good thing! You are in the best position to remove one UB.

  • Don't keep the old compiler just because you are afraid of UB. Recompile the project with the latest and best compiler available. Compilers can also have bugs. Newer compilers will produce better, more robust code. Newer compilers will produce better warnings. Use all warnings possible -Wall.

  • Eliminate all the warnings that the compiler produces. Every single warning is there for a reason, it highlights a problem. The likelihood of a "false positive" is quite dim nowadays. This is even true for MSVC (I'm not talking about real old compilers like before VC 2005)

  • Use a static code checker (Cppcheck). It can point you to common problems with the code.

  • Use a custom rule set for your code checker. It will help you to get the code up to some standard.

  • If possible, compile the project with another compiler (GCC, Clang) just for the sake of getting the warnings of these compilers.

  • Don't link against old object files. This will create more problems than what you think it avoids

Upvotes: 3

sholsapp
sholsapp

Reputation: 16080

In order, I would:

  1. Compile with -Wall (/W4 for you Windows folk) and fix errors.
  2. Write tests if there aren't any already.
  3. Use tools like valgrind to detect issues and fix them.
  4. Study synchronization primitives if in use, and use modern paradigms where possible.
  5. Document the code and adhere to a style guide.

I would not attempt to avoid problems by keeping object files around. That's a nightmarish maintenance problem.

Upvotes: 4

Related Questions