Ten years ago, we created a simple utility called Viva64 intended to detect problems in the 64-bit code. This is how PVS-Studio static code analyzer came into being. Although 10 years passed, we started doing something more or less worthy as a company only several years ago. This article isn’t a “success story” because we think that the most interesting events are yet to come. However, 10 years is quite an occasion to assess some results of our work and to tell our readers, how it all started, which errors we made and what we finally did right. Perhaps, at times, I will be not very precise in the chronological description of the events. 10 years is a long period of time and the memory is not perfect. Enjoy reading!

Background

Me (Andrey Karpov) and Evgeniy Ryzhkov worked in a small company in Tula, which was working on the creation of numerical simulation packages and data visualization. This job was rather interesting and we could use and get in touch with the cutting-edge technologies of that time. For instance, working on the visualization of data, we experimented with 3D glasses, which worked on the principle of closing the eyes by-turn. The images were displayed on a CRT monitor that showed a picture for the left, then for the right eye. I think very few people saw such an ancient thing: the glasses were connected to the computer with a cord, the CRT monitor was running in the interlaced mode (100 fps) so that each eye had at least 50 fps. It looked really horrible, the eyes started to hurt instantly, so it was no surprise that this technology didn’t get much popular.

Another thing that we did, was making a budget cluster, using simple PC motherboards. We used motherboards with two physical AMD processors. Today nobody will be surprised by a processor with 8 kernels, but at that time a motherboard with 2 kernels was a real wonder in an average shop in Tula. We have combined 4 boards and got an 8-kernel mini-cluster, which we used for various calculations. I personally took part in soldering this device:

Figure 1. A cluster built with the material we had at hand. Characteristics: 8 CPUs, 16 gigabytes of memory.

It didn’t look very nice, as we didn’t manage to solve the problem of ventilation and we had to remove the back cover, sacrificing the outer beauty of the device. However, the cluster coped with the tasks quite well.

Also, we dealt with the first 64-bit computers, available to ordinary users. These were the machines with Opteron processors and a huge, as it seemed at that time, 4 gigabytes of memory. So, it all started with those machines.

In 2005, Visual Studio 2005 was released, which made it possible to develop 64-bit programs from the 64-bit architecture (at that time it was called AMD64). I remember going to a Microsoft conference in Moscow, where it was demonstrated how to easily recompile the code for a 64-bit processor. In general, 64-bit technology was an important trend in the development of computers.

Of course, 64-bit microprocessors existed before that too, for example, Itanium. But is was AMD64 that had a major influence on the IT-industry: due to it appeared the 64-bit processors, available to everybody — Windows-programmers now had a possibility to write programs for these processors in the comfortable Visual C++ development environment.

The memory space is extremely important in the tasks of the visualization and numerical modeling Therefore, immediately after the release of Visual Studio 2005, we started working on 64-bit applications.

It was no surprise that we were among the first programmers, who were adapting their application code for the 64-bit processors, and as a result, stepped on a lot of rakes. For example, we found out that the hardware keys for the program distribution aren’t quite ready to be 64-bit yet. I cannot recall, what exactly was wrong, but we really had to take trouble over the new variant of code protection. There were some other nuances about the creation of distributions, but these are all details: the most interesting happened later.

Microsoft didn’t lie — we really managed to recompile our applications in the x64 mode quite fast — it took us about 3 weeks. At that moment it seemed to us that we got a 64-bit distribution of our applications.

Ha! We did it, but the programs worked incorrectly. Moreover, there was some trick in all of it. The programs were successfully passing the unit tests and worked correctly on the test data. But when we wanted to use the whole the power that a 64-bit application provided, we had some strange errors. The program was glitching up, when it allocated more than 10 gigabytes to handle large input datasets.

Figure 2. I don’t have the pictures that could demonstrate the errors of visualizing errors in a 64-bit application, I couldn’t imagine that after many years I would need them. But this picture is very similar to the result of errors that I saw. Suddenly, we could see only a part of the object on the display.

Now I know the causes of such strange behavior of the programs. In some fragments the pointer was turned into int, and then back to a pointer. If the pointer was referring to an object in the lower 4 gigabytes of memory, so it was all fine. But if the object was created in the memory, exceeding the 4 gigabytes, the problems were inevitable.

There were errors in such evaluations:

unsigned int X, Y, Z;
Uint64 Q = X * Y * Z;

Although the result is a 64-bit variable, it doesn’t help — the overflow occurs when 32-bit variables multiplied.

Of course, there are a lot of other ways to shoot yourself in the foot. You can find more details about various 64-bit pitfalls in this article: “A Collection of Examples of 64-bit Errors in Real Programs”

At that time, in 2005, the things happening to our programs seemed as some strange magic. What’s more important, we had no idea how to find and eliminate such defects — all our methods ceased to work unexpectedly.

Once again, the unit tests were running correctly and did not reveal anything, everything was fine with the small test data as well. It’s almost impossible to debug on large amounts of data. Firstly, it is very slow. If the release is supposed to work for half an hour so that the errors start showing up, the debug version of the program works for long hours. Secondly, it is unclear what should we look for in the debugger. Should we start examining billions of the loop iterations to find where something goes wrong? Programmers always try to use a minimal set of data to reproduce the problem doing the debugging, but we see that everything is fine in the small sets.

We decided to use a BoundsChecker program, which was quite popular at that time and helped us several times already. But it turned out that it is not able yet to work with 64-bit applications. However, even if it worked, I don’t think it would be of great help. The program speed when using BoundsChecker slows down in dozens of times. I think for our cases this would result in days of waiting.

We realized that got into an impasse: we know that there are errors in the program, but do not know how to find them.

Our team began studying the situation in more detail. We were experimenting a lot and surfing the net to find at least some information. Gradually it became clearer what we were dealing with. We began to understand what bugs lived in our programs but it wasn’t much helpful. Let’s say, we suspect that arithmetic overflow is to blame for some errors. What’s next? How can we find them, those fragments?

Being really frustrated, we started looking for new ways out. We considered an option to replace all the integer types with special classes, such as SafeInt. This would allow at least to find integer overflows. However, it turned out, that it’s very difficult to do it for existing applications.

After that we tried out some tools of static code analysis and even bought Gimpel PC-Lint — the analyzer which wasn’t really useful. It wasn’t meant to look for 64-bit errors.

That was the moment when we realized that we are the first people to wonder about it. 64-bit errors existed, but the world didn’t have any solutions of how to solve them.

How we did we sort it out? We decided to read the code, of course, not all of it. We configured PC-Lint so that it issues a warning for all the explicit type conversions, implicit extension of int into 64-bit types, and so on. Of course, we had an incredible amount of useless warnings, but still it was better than just reading the code from the beginning to the end.

We reviewed potentially dangerous fragments, that PC-Lint pointed to us, after we set it up in a special way. We also read the most important modules and functions. In several months we finally got a stable version of 64-bit applications.

As you have probably guessed, only two people were involved in the task of porting to a 64-bit system: me and Evgeniy Ryzhkov.

Conclusions we made:

  • when porting systems to 64-bit, people will have to face 64-bit errors;
  • these errors are very difficult to search for;
  • there are no tools that help find such errors.

Around the same time, another fatal event happened. Evgeniy Ryzhkov became very keen on reading books about start-ups and a new trending direction ISV (Independent Software Vendor). However, there was no such a word as “startup” at that moment. At least in that meaning that we use it now.

11 years ago the cell phone industry wasn’t that developed there was no AppStore and things like that. If it had been there, perhaps Evgeniy would have started creating games for phones and tablets. At that moment, he was confined to an ordinary computer. He tried to make his own application — a coloring “book” for kids and tried to sell it. In general he managed to do it and started selling it, but it was not something that would lead to success and serious profit. He started to look for new ways to apply his knowledge.

I also had some entrepreneurial bent and wanted to create something of my own, but these ideas didn’t have a precise form and were just thoughts. Right then Evgeniy suggested to think about creating something that would conquer the world and make us rich and famous — the classic dream of a startaper was really contagious. So, we started thinking hard.

Viva64 version 1.0

What we had:

  • two people who want to organize some kind of a start-up;
  • these two people are aware that there is problem of searching for errors in the 64-bit programs in C++.

It would seem, what is there to think about? We should just start making and selling a tool that would look for 64-bit errors. It took us quite a long time to come to this understanding. It seemed to us that it is a complex and obscure task that no one know how to solve, since there are no tools for that.

First, we went through some plain and simple ideas. We didn’t want to make sites, we wanted to create a finished software product. But the trouble is that we didn’t understand what we can offer the world. We wanted to chose a direction, that will be on demand, not just some abstract great idea.

In some time we really started to think over a tool that would search for 64-bit errors in the C and C++ programs. In the beginning we were estimating — what could it be. At first we thought that it could be something like a dynamic analyzer like BoundsChecker. However, it was too hard, plus it was unclear how to look for some particular bugs.

Gradually we came to the realization that it should be a static code analyzer, i.e. a program that points a programmer to the areas of code which need to be reviewed. We thought we should create a tool like PC-Lint or Parasoft C++test, but just aimed at searching for specific types of errors.

The important question was if we were able to make such a tool, because it was about the C++ code. We had to study this question too.

There was no LLVM at that moment, that’s why we were considering a variant of taking the GCC compiler or some open source library as a basis. Of course, there were paid libraries to parse C++ code, but we didn’t even think of them. GCC seemed to be too complex and ponderous, plus it was unclear, if we could create a closed project on its basis. We didn’t want to make an open project, because we didn’t see how it can be a way to make a living on it. As a result the choice fell on an unknown OpenC++ library. By that moment the library had already been abandoned, but this didn’t stop us, it seemed quite simple to us and we managed to write a small diagnostic with its help quite fast.

So, we have cleared out for us the main direction — that we are going to make a tool that looks for 64-bit errors in C/C++ code. This will be a classic static code analyzer, but we tried to avoid such phrases at that time — we thought that it would mislead those people who would search in the internet “a tool to search 64-bit errors”.

Having the experience with using Gimpel PC-Lint, we decided that we would make this tool as a plugin for Visual Studio. Back then, you had to use almost magic spells to use PC-Lint from Visual Studio. I wrote a post on this topic that turned to be quite popular, by the way: Installation of PC-Lint and its using in Visual Studio 2005. In general, we thought that this integration didn’t really fit us and we have to provide users with a convenient interface: a person should install the tool and see the possibility to start developing the project. This is the principle that our team is still using and thinks it to be very important.

At that time we imagined Viva64 to be a simple utility, that we would sell for $200, but massively. We thought that a demand for this tool should rise dramatically, caused by the global rewriting of programs for 64-bit processors. Here was our plan: we make a simple tool, that will be super necessary for people, then we will be selling it for 3–4 years. Then, after gaining a huge profit on this genius idea, we’ll move on to some other project. These were our youthful fantasies of a cool idea and our quick way to richness. We even made such a graph, showing how the demand would look like.

Figure 3. In 2006 Evgeniy came up with such a graph, showing the supposed demand for the solution of checking the compatibility of the C++ code with the AMD64 platform. We were presuming that the demand will decrease in 2010 and Microsoft will release some standard solution, which will force out Viva64 analyzer from the software market. Still, we were hoping to get the best in the nearest 2–3 years and save some money for the future endeavors.

Being so inspired by the dreams about the immediate success, we started programming, creating the source distribution and the first version of the site. We were doing it all in the evenings, because during the day time we were still working in the office full time. The path from the idea to the first version took about a year.

Finally, the day X came. December 31, 2006 year, we posted the first public release of Viva64 1.00 on the Internet. I remember that Evgeniy told me to do that before the new year, so that the version history would have the year 2006 — it would seem to the users that the tool is already a year old and it would seem more solid. Now, after a long journey of 10 years, it all looks naive, but then it seemed very important.

The budget of creating the first version of the analyzer and the site was 43 200 rubles. Of course, our work time isn’t included in this price, these were additional expenses. For a better understanding, let’s calculate this amount of money at the exchange rate of the year 2006 — it was about $1710. We can say that we didn’t spend much on this new project.

Starting with 2007, we started selling our tool, gradually improving it, so the workload increased. Besides the programming tasks on our regular job and programming the analyzer we had to somehow promote Viva64 among the programmers. We started learning how to write articles, response of the forums, try out some variants of paid advertisement.

This tempo of life quickly burnt out our moral and physical resources. Additionally, the things weren’t going well in the company we worked full-time; we realized that can no longer work like that and decided to leave the job.

Still, there weren’t many sales; we managed to sell several copies, but there were so few, that it’s not even worth mentioning here. We even tried to withdraw the money that the reseller account, as this sum wouldn’t be of any help anyway.

It was a hard time for us — there was less and less money over the time, but there was nowhere to get it from. We had a great temptation to quit and just get a job somewhere — but we tried not to give up. We were comforted by the thought that the programmers are always on great demand and we would be able to get a job somewhere within a week, if we go bankrupt at all.

Of course, we were looking for all possible variants to find finances, so that we could continue the development and for some reason we believed that we had just to wait a little and there will be a huge breakthrough. There a lot of chaotic actions at that time, which I don’t remember clearly already. For example, once we decided to visit the AutomatedQA company (Smartbear nowadays, having the office in Tula) and talk to the director, Sergey Lisitsin. We showed what we had, tried to arise some interest in this tool, but these weren’t successful attempts. Although, perhaps we were just knocking on the wrong doors and couldn’t present ourselves properly.

We had to deal with this situation somehow, because Viva64 was refusing to become popular and famous. This pushed us to working outsource and we were eager to do anything that was at hand, Ingate and Intelsys companies were among those that we worked with at some point. Later we took part in a large project of an italian company; it was a program for dental technicians who were making dental prostheses. The dental bridge or a crown was designed on the PC, and then a special machine cut the prostheses out. In fact, it was a highly specialized CAD system. We had to go back to the section of mathematics related to the rotation matrices and transformation of images, and learn what is NURBS surfaces are.

Figure 4. One of the stages of working with a scanned jaw to create a bridge. Note that to the left several teeth are missing, two teeth are already grinded down, so that the technician could project a bridge that will be fastened on top of them.

Again, the workload for us increased dramatically. We were spending 8 hours working on the CAD system, and then, depending on the energy resources, worked on the improvement of Viva64 analyzer, the site and did something about the promotion of it. The positive thing was that there was no need to spend time to get to the office, as we were working from home, but it’s hard to say what’s easier — sitting at the computer the whole day is also very difficult. Apparently, this is the only way out if you want to do something extraordinary — you have to work even harder to see some changes.

The popularity of Viva64 was gradually growing, but very slowly. We starting realizing that we didn’t have such a quick start that we dreamed about. There was some naive hope that it would happen, just a little bit of patience and 64-bitness will be a crucial question among programmers.

To cut the story short — the 64-bit has never had that demand that we were expecting. The programming world was slowly moving from the 32-bit to 64-bit applications and it is still continuing. Until now, some clients choose PVS-Studio, solely due to the fact that it has diagnostics that detect problems related to the 64-bitness.

Which means that we were wrong and right about the topic of 64 bit at the same time. We were right that there are real problems of migrating a large code base to the 64-bit platform. For 10 years we have sold quite a number of Viva64 licenses and later, PVS-Studio tool that looks for 64-bit errors. We were wrong about the time intervals. Our thoughts were that the transition would be going for 2–3 years and then it would be slowly declining for another couple of years. Having these ideas in mind, we started this project. Hoping for a sprint, we have started a marathon that we are already running for 10 years already.

However, now we understand what was it all for. At that time we continued believing in the “64-bit development” and went on improving the analyzer.

Start 2008, point of no return

In 2008, the fortune led us to a state program Start. To be more exact, we started preparing for it in 2007, but got the finances only in 2008. In a nutshell, here is what it is. A quote from the site:

“The objective of the Program is the facilitation of innovators, seeking to develop and master the production of new goods, products, technologies or services using the results of their technological research results that are at an early stage of their development and have a great potential for commercialization. It should be borne in mind that the “start program” is primarily focused on the initiative of researchers wishing to create a steadily operating business based on their innovative ideas.”

Saying it in simple words, here is the case: a person tells about an innovative project, the program gives a grant for its implementation and checks if you reach the stated results. If everything goes well, the funding may be extended for a second and then a third year. By the way, the program is still working now.

We have mixed feelings after the participation in this program. On the one hand, there is a lot of red tape and formalities. On the other hand, this programme stimulates moving to a new level. Overall, I will give a positive assessment of this idea. The participation in this program gave a great stimulus in various directions.

First, you have to have a limited liability company. Then you are provided with some finances (at that point the sum was 750 000 rubles for s year ($30 000)). But it’s not that easy to spend this amount of money — you cannot simply go and buy PCs and ad banners; at the same time it would be silly not to spend it. As result, the need to do something with the money made us rent the first office, hire two first employees and buy some furniture for the office and so on.

Figure 5. OOO “Program Verification Systems”, 2008 year. The first day in our first own office. You can click on the picture to enlarge.

So, the participation in the Start program forced us to finally leave the houses and start really working on the Viva64 project, not just playing around with it. The Start pushed us to register the LLC, hire first employees and feel like real organizers of the company — this was the main value of this program for us.

It helped us to think of ourselves not just as programmers with an interesting technical project, but as entrepreneurs: it served as a catalyst for our project. It made us leave the comfort zone and start setting bigger goals tasks. We are really grateful to the government and to all who are organizing this program.

This is probably enough for positives sides, now’s the time for a fly in the ointment. The participation is awful bureaucracy and it takes a lot of days to prepare the technical and accounting reports. On top of it, you are rarely able to spend the money on those things that are really needed, as a result you have to spend the money on useful, but secondary things. It is hard to explain it, you have to try it yourself, to see what it’s like, but believe me, there is a lot of turmoil and limitations. It is clear that all these restrictions are made in such a way, that people could steal less money, showing only the fiction of work. However, it’s not the best relief for honest participants.

You have probably already understood that the finances, given by the fund didn’t cover all the necessary expenses; we were still working in the outsource for the dental company, but just sitting in an office. Once more, the workload increased. Besides the outsource work, the analyzer development and its promotion we now had to work on the documentation for the fund: preparing the reports and going to Moscow to hand them over.

It was hellish. When 2008 was over, we decided that we aren’t going to continue the participation in the “Start” program — the bureaucracy was taking too much time, and the efforts we were putting in it were mostly wasted. Around the same time, there were more sales of Viva64 and we clearly saw that we weren’t devoting as much time to as we could have. We decided that we would rather tighten our belts and focus on the perspective directions, rather than filling up tons of reports. We did not apply for the following year. Such a decision may seem silly, but I’m sure that we did the right thing and possibly saved a 1 or 2 year.

I mentioned that there were sales of Viva64, it was really so. Later we started rising up the price because our clients were quite large companies. That was the moment when we got a suspicion that we were making a tool not for single developers, but for companies; still we were far from realizing that we are a B2B company.

VivaMp, the first mistake

We have made a lot of mistakes for ten years. I won’t be telling about small ones, because it’s not that interesting and I don’t remember everything accurately. As an example of such a small mistake was that our company worked on the general system of taxation, when we could use a simplified one. We didn’t know that we could apply for a simplified system in the first 5 days — a typical error of beginners. It wasn’t awful for us, as our company didn’t earn much and therefore, we didn’t spend much too.

So, let’s speak about more epic fails. The first was the VivaMP project. We started this project back in 2008, but the first release happened only in the March of 2009.

We have already accepted the fact that the 64-bit idea didn’t give us a quick start, so we decided to look for a new direction, where we can get ahead of others. It seemed to us that we did it — in 2008 multicore processors started appearing massively.

And the programmers had to choose which technology would dominate in the sphere of developing parallel programs on C and C++. There were different variants: MPI, OpenMP, some existing library or something that may soon appear.

The Intel company was promoting the OpenMP technology, or, at least it seemed to us so. We thought we could repeat the same venture experiment: create a static analysis tool for parallel programs built on the OpenMP technology. In general, the static code analysis of parallel programs is an unsolvable task — the dynamic analyzers are much more useful for it. You can do some analysis of parallel programs, but the code should be marked up in a special way, giving a hint to the analyzer about the fragments that would be executed parallelly and which — not. In this regard the OpenMP technology is extremely favorable for the analyzer. The “#pragma omp ….” directives are that very markup for the analyzer.

Therefore, we studied in detail the topic of programming with the help of OpenMP and were quite sure that there are errors that we can detect with static code analysis. Those who are interested, can have a look at our article: “32 OpenMP Traps For C++ Developers”

All in all, the new direction was also chosen incorrectly. It was absolutely wrong. While in the case with the 64-bitness there was some interest among programmers, although it wasn’t as big as we would like it to be; in the case of OpenMP direction there was no interest at all.

Apparently, there were several reasons for this misfortune:

  • The OpenMP technology didn’t become mainstream. It is as usual as the other technologies of parallel programming for the programmers.
  • Which means that not so many developers really use OpenMP in the projects. Consequently, the demand will be small in any case. Besides that we didn’t manage to reach that group of developers and spread the word about the existence of VivaMP tool.
  • Altogether, static analysis is quite weak in the search for errors in parallel programs in comparison with other tools.

The VivaMP project also failed — there was nobody who needed it. There were almost no questions in the mail about this analyzer or reports about the bugs found in it — the world just ignored the existence of this tool.

Further on, VivaMP was integrated into PVS-Studio and later removed at all. The OpenMP continued developing and it obtained new possibilities and new keywords. It requited some support, but there was no point in doing it for a stillborn tool — it would be just a waste of time. We braced ourselves and deleted this part of the analyzer.

So, VivaMP is our first great failure. It took us a lot of efforts and time to create and promote a new tool.

Despite this misfortune, we found the courage to stop working as employed programmers and devote the full time to the development of the analyzers. Viva64 began bringing some profit, it wasn’t quite small, but enough for autonomous existence. At that time we were earning much less than we could have, if we had gone working to some software company as programmers.

PVS-Studio and the general analysis, first success

In the year 2009 we combined Viva64 and VivaMP into a single product in hopes that the diagnostics of VivaMP will get bought as some addition to the 64-bit diagnostics. Again, this didn’t bring any result, so there is point to continue talking about this.

Nevertheless, we should consider 2009 as an important milestone in the life of our company. This was the year, when we released PVS-Studio which was initially the combination of Viva64 and VivaMP.

By the way, let’s talk about the names of the tools. The analyzer Viva64 appeared as the idea: “Long live the 64-bit world!”. The very word “viva” was in my mind because of a song that I heard before “Viva Forever”. I suggested using this very title to Evgeniy, and he agreed. Our site www.viva64.com was called in the same way, as there was no point to rename it — this title became quite popular over the time.

The PVS-Studio name was created in a more complex way. The first three letters is an abbreviation of the name of our company OOO “Program Verification Systems”. “Studio” was added to emphasize that it’s not just one tool, but a set of tools. Actually, the title is not very apt, as it is often misspelled: people forget the dash and write PSV instead of PVS and so on. If we were to choose a name now, we would chose something simpler. That was our idea behind the name for CppCat, but it it a completely different story, which I will tell later.

Let’s go back to the main idea of this story. In 2010, we thought that we could increase the interest in PVS-Studio, adding several diagnostics of general analysis. We were planning to make these diagnostics free, because we didn’t really believe that they would bring any profit. In the sphere of general analysis diagnostics there were already such tools as Coverity, Parasoft C/C++test, Klocwork, Gimpel PC-Lint and other unarguable leaders on the market. We didn’t mean to compete with these tools in any way, that’s why we were planning to make the free diagnostics only as a means of advertisement. The idea was the following: a programmer checks his project for free, then he learns about paid diagnostics for 64-bit errors and OpenMP technology.

In November, 2010 we released a beta-version of PVS-Studio 4.00, with a new set of general analysis diagnostic rules. At that time there were 45 of them. Here’s an article about this event: “Let the world tremble! We’ve released PVS-Studio 4.00 with a general-purpose analyzer!”.

Later happened a key event, which actually changed everything. We can say that that was a turning point when we moved from the unpopularity to a successful strategy of behavior. Of course, it was too early to speak about some huge success, but things started changing.

Here is what happened: some programmer contacted us and wrote about our general analysis diagnostics, asking how much he has to pay to get them. We replied that they are free, but he may buy the 64-bit diagnostics that are extremely useful. His response was that he needed neither the 64-bit diagnostics, nor VivaMP. He thanked us a lot for such a cool tool and for that he could carry on using these general analysis diagnostics for free.

We heard the signal from space and quickly reconsidered our approach. So, PVS-Studio 4.00, which was released in a month became paid. We even had to write an article to explain why we changed our mind so quickly: “What is the reason for making PVS-Studio 4.00 a commercial solution? :-(“ In a nutshell, the idea of it is that “we just want money”, so you may not even read the article.

Finally, PVS-Studio turned into a set of three analyzers (Viva64, VivaMP, diagnostics of general analysis), which we started selling as one tool. In this version we also made the first corporate licenses (Site License).

As the time was going by, PVS-Studio analyzer was gradually developing and bringing more profit. PVS-Studio 4.30 obtained the incremental analysis — an ability to run the analyzer automatically for those files that have just been edited or recompiled. It allowed using PVS-Studio regularly on the local machines of developers.

In PVS-Studio 4.32 that was released in July of 2011, we stopped selling a single-user license. That was one of the best business-solutions in the company history. We came to the understanding that PVS-Studio is a team tool, which is useful for the whole project, regardless of the number of people working on it.

In the beginning of 2012 we released PVS-Studio 4.53 that already had 100 general analysis diagnostics (V501-V600). Quite soon, there appeared a new set of diagnostics in PVS-Studio 4.60 “Micro-optimizations” to search for those fragments of performance loss, that can be detected by a static analyzer.

3 years passed, before the moment when we finally made correct decisions concerning the development of the project. But that was too long, it was time to do something stupid.

Embarcadero RAD Studio, the second mistake

It will be a short story, as there is nothing much to tell about. PVS-Studio 5.00 had the integration into Embarcader RAD Studio. We thought there were a lot of users of C++Builder, but we were wrong, or, we just haven’t found them.

In general, the story was similar to VivaMP. Yes, RAD Studio is used somewhere in the world, but very little — there was no interest from the programmer community. Just like with VivaMP, there were neither e-mails with questions, nor messages about the errors in the tool. Just silence.

Of course, we spent a lot of time and efforts on the support of Embarcadero RAD Studio and the advertisement of new possibilities.

But these crazy ideas about Embarcadero RAD Studio weren’t mad enough for us, in a year we did another serious mistake.

CppCat, the third mistake

We released CppCat 1.00 — a cheap version of the analyzer, based on PVS-Studio. We called it “PVS-Studio version for 250$”. The idea was to make a high-quality low cost analyzer — it was much cheaper, so that supposedly, more individual developers would buy and use our solutions. Perhaps, we would even abandon PVS-Studio that we saw as a large and a complex program with a long history, as opposed to an easy and small CppCat, where a simple interface was combined with powerful code analysis.

I think, by the title of the chapter you have already guessed that it was a bad idea. I decided not to describe the details of this error, as they would basically repeat the article “We are Closing Down the CppCat Project”. I highly recommend this article for reading, it is small and very interesting.

Figure 6. The CppCat project was great in everything. It had a simple title, easy settings and any individual developer could afford it. The bad thing about it was that it wasn’t bringing profit.

A little more than a year later, we closed the CppCat project, having wasted a lot of time and effort … again. As you can see, we have done a lot of serious mistakes, and each of them could easily bankrupt us. Now we are much more accurate and think more thoughtfully about new experiments, laying aside some resources in advance in case the idea would fail again.

By the way, a little before closing the CppCat, we removed the support of Embarcadero RAD and OpenMP diagnostics. We realized that it was time to get rid of the ballast that does not bring any profit, but still requires a lot of efforts to maintain.

Nowadays

Failures with CppCat, VivaMP, Embarcadero RAD Studio didn’t make us devoid of the enthusiasm and we decided to invest our energy into three new directions:

  • Analysis of C# code;
  • Linux Support;
  • A free version of the license for PVS-Studio.

It is still quite early to speak of how successful are these ventures — we will see it only in several years. We are still full of energy to conquer the world and we see that it is gradually happening.

We can consider the start of our company as the year 2009, but we went to the self-sufficiency without the support of outsource projects. At that time we had 4 employees. 7 years later our team has 24 people. Of course, we cannot call it a huge success, but it is in the way it is. I don’t see any point in making the situation look better than it really is. Despite the 10 years way we are still in the beginning of the journey, we are just learning to really make and sell the software product.

I hope, that was an interesting story. I’ll be glad if it inspires someone not to disregard small beginnings and continue believing in a dream.

Figure 7. Never give up!

Oh yes, bugs in Viva64 v1.0

It wouldn’t be me if I hadn’t checked the first version of Viva64 analyzer with the current version of PVS-Studio. There weren’t a lot of errors actually, due to the tiny size of the analyzer kernel of that time — there were about 3–4 thousand lines of our code. The analyzer kernel Viva64 had only 210 files and was 37 KLOC. For comparison, now the kernel of PVS-Studio for C/C++ code is now 320 files and 208 KLOC. Accordingly, the amount of code we wrote increased around 40 times.

Note. Let me clarify once again that we are talking about the kernel for the analysis of C/C++ code. On top of it, there is a plugin for Visual Studio, the C# kernel, Standalone utility and many more. Therefore, the total code size uncreased in hundreds of times.

So, let’s see the warnings of the current version of the analyzer, which seemed interesting enough to include them in the article.

rw_table_sanity_check(const rw_table table[])
{
unsigned n = (sizeof table)/(sizeof table[0]);

if (n < 2) return;

 for (const char* old = (table++)->name; --n; old = (table++)->name)
if (strcmp(old, table->name) >= 0) {
cerr << "FAILED: '" << old << "' < '"
<< table->name << "'" << endl;
assert(! "invalid order in presorted array");
}
}

This error is detected by two warnings of PVS-Studio:

  • V511 The sizeof() operator returns size of the pointer, and not of the array, in ‘sizeof table’ expression. lex.cc 822
  • V514 Dividing sizeof a pointer ‘(sizeof table)’ by another value. There is a probability of logical error presence. lex.cc 822

The error is related to the subsystem of unit-tests. The test checks nothing, because the n variable is assigned with the 0 value. The error that the table is just a pointer, not an array.

Here is my own error:

bool IsLiteralFFFFFFFF(const char *buf, size_t len) {
if (len < 10)
return false;

if (buf[0] != '0' && (buf[1] != 'x' || buf[1] != 'X'))
return false;
....
}

PVS-Studio warning: V547 Expression ‘buf[1] != ‘x’ || buf[1] != ‘X’’ is always true. Probably the ‘&&’ operator should be used here. vivacasts.cpp 632

The quick check that the literal should start with the “0x” or “0X” symbols. The check considers all strings, which start with the ‘0’ character to be correct.

The following code fragment is quite long, but I decided not to shorten it:

Ptree* Append(Ptree* p, Ptree* q)
{
Ptree *result, *tail;
  if(p == 0)
if(q->IsLeaf()) // <=
return Cons(q, 0);
else
return q;
  result = tail = Cons(p->Car(), 0);
p = p->Cdr();
while(p != 0){
Ptree* cell = Cons(p->Car(), 0);
tail->SetCdr(cell);
tail = cell;
p = p->Cdr();
}
  if(q != 0 && q->IsLeaf())          // <=
tail->SetCdr(Cons(q, 0));
else
tail->SetCdr(q);
  return result;
}

PVS-Studio warning: V595 The ‘q’ pointer was utilized before it was verified against nullptr. Check lines: 360, 374. ptreeutil.cc 360

There will be a null pointer dereference, if both factual arguments are equal to nullptr.

The following code is quite justified for those times, but now you cannot code like this:

Class* Environment::LookupClassMetaobject(Ptree* name)
{
TypeInfo tinfo;
Bind* bind = 0;
  if (this == 0) {
TheErrorLog().Report(
MopMsg(Msg::Fatal,
"Environment::LookupClassMetaobject()",
"0 environment"));
return 0;
}
....
}

PVS-Studio warning: V704 ‘this == 0’ expression should be avoided — this expression is always false on newer compilers, because ‘this’ pointer can never be NULL. environment.cc 115

There are ten more checks like these.

And… that’s it. Probably, the readers would expect more, but there is really nothing more that deserves attention. 37 KLOC is really very little and we have always been very careful about writing the code and testing.

Conclusion

A couple more interesting observations. 10 years ago I really thought that the organization of the working processes in a company would be different. Once it seemed to me, that when the company becomes larger, we’ll do some creative tasks, think of the development strategies and seat in leather arm chairs with a smart and thoughtful look. But it turned out that as the work goes on, our job resembles the job of firefighters who must selflessly fight with different troubles. The more space we are taking and the more employees we have, the more “emergencies” we have and the more various they are. Examples: issues with electricity, leaking ceiling, jamming door lock, dealing with the “violations” of unpaid taxes — 1 kopeika (1 penny) and so on. This doesn’t mean that we are going to fix an air conditioner, which was hit by an icicle ourselves. But it would be our task to organize its fixing.

Figure 8. Quite a fresh winter problem. Here are common troubles of startups. They aren’t really caused by an incorrectly chosen framework.

Sometimes you have to use real instruments and something, so that things work.

Figure 9. Here is me and Sergey Khrenov, fixing a Press Wall. If you want to do something well, do it yourself. You can click on the picture to enlarge.

Perhaps, this is a typical transition step for any company, when the organizers have to do a bigger amount of tasks, which have nothing to do with the project itself, but the tasks just need to be done. Over the time the company should get a supply manager, a lawer, an administrator that would fulfill a part of those tasks. We aren’t big enough for, but we are doing our best.

Thank you for attention. That’s it about the story of our failures and successes and I wish you Happy New Year and great holidays.

Article republished by the author’s permission.



SOURCE

LEAVE A REPLY

Please enter your comment!
Please enter your name here