As a test of my new computer build and to make sure I have my base development setup I re-started working on a C++ project . This project uses the rapidyaml library to parse yaml in C++. The rapidyaml library in turn relies on the c4core library of utilities. All good so far? While building the EveSDEImporter project with Visual Studio 2019 I found that I was getting warning C4296 that a >= comparison was always true. Looking into the comparison I found that a std::size_t parameter was being checked to see if it was greater than or equal to 0.

Why Is Comparing size_t >= 0 A Problem?

If you follow the link to the Microsoft documentation you’ll notice that warning C4296 is off by default. This means that the warning level has to be up pretty high in order to see the warning. And, in my case, it was a hard stop because the settings I pulled from the C++ starter project treat warnings as errors.

So what is the actual problem in this case? It took me a moment (and a reading of the std::size_t cppreference page) to realize that this comparison will always be true because size_t is an unsigned integral type. It is up to the compiler to determine what actual type it is (short, int, long, long long, etc) but it is intended to be unsigned. By default an unsigned integral type will always be 0 or greater. Because it does not make sense for a type representing the size of something to be less than 0 it is sensible to define such a type in a way that cannot be less than 0.

What Did The Code Intend With The Comparison?

While I’ve not spoken with the author of the rapidyaml or c4core libraries the context of the code and intended use of size_t give us clues. In each of the cases that this warning cropped up the variable being checked was a parameter to a function. The comparisons were happening in ASSERT() statements that we’re making sure that the parameters actually contained data to act upon before actually doing anything with them. As such it was a sensible change to change the comparisons to simply greater than 0.

Conclusion – Warnings Catch Bugs!

So, in short, it is helpful to turn compiler warnings all the way up and treat warnings as errors. Make sure that you heed the warnings you’re getting. The folks who are writing compilers are typically very smart and also tend to hear back quickly when there are warnings/errors that aren’t being shown correctly. Make sure that you have a very good reason if you’re going to ignore a warning.