Effective ways to debug and enhance the quality of your Embedded Software using Polyspace Static Analysis Solutions

Hello, everybody. Welcome to this webinar. Sorry that we had to start a little later. But we'll make up for that. Thank you all. I hope my audio is clear and you're able to see my screen also clearly. So just to give a heads up, you all can probably give a thumbs up or something.

All right, so beginning now, so we have our webinar today. And this is mainly around effective ways to debug and enhance the quality of your embedded software using Polyspace. So this is a part 1 of the series, where we are going to be moreso discussing of how Polyspace can be used more into a developer's environment. And later in the part 2 of the series, we will be discussing more on the different workflows that are possible with Polyspace, which will also deal with the continuous integration, collaboration, and many other related workflows.

So today, I will be the speaker for this presentation. So I'm Vaishnavi. And I work at MathWorks as the application engineer, mainly handling the Polyspace products across India. So I deal with customers from various different industry segments from aerospace to automotive, semiconductor, medical, et cetera.

So this is a brief background about me. So prior to MathWorks, I also worked in supporting verification workflows at various different organizations, especially to do with the aerospace industry, like Collins, where I've also supported certifications around DO-178, et cetera.

So along with me today, I have Amal K. Sebastian. He is our product overlay sales. So he comes with a very rich experience for about more than eight years. He has technocommercial experience. He has worked at NI and AvGarde. And he is representing the Polyspace product and its sales for all over India. So me and Amal would be your contacts for today for any of your queries, for anything further discussions on Polyspace, and any of your interest regarding this field. So feel free to contact us.

So beginning today's presentation with this sentence, which I'm sure all of you will agree with, which is "Software is eating the world." I am sure all of you are in agreement to this because if you look at this graph or a trend, which is a survey conducted by the Deloitte, it shows that a large chunk of your own-- if you see the various different industry segments, the chunk of the software has been increasing tremendously, which is quite evident over here.

So I wouldn't say a word more than this because we all know that software is becoming immensely important. And it's gathering-- it's become a major chunk of any industry we go through. And that, in turn, translates to bringing about a lot of pressure or challenges to developers, developers or engineers, whoever you may want to call them. So all of us are faced with a lot of problems-- not only problems, I would say more challenges today because we're dealing with more complex code.

We are dealing with various different factors, like requirements which are taking shape nearly every day. I would say this is like the changing requirements problem, where we all are remotely located and working in collaboration with multiple different teams, which are geographically located. But we have tighter deadlines. And obviously, there is so many other aspects.

And as developers especially, producing quality code is something which is very important. And also dealing with the type of code we are looking at today, it is also becoming very challenging for us, as developers or as engineers, to use quality code. So we also need to up our game by using advanced or quite advanced technical solutions to match up the speed with which-- how the software is taking shape in this world. So with that in mind, today's focus is especially on effective ways in which we can debug and enhance the quality of our embedded software by using a solution by MathWorks, which is called as the Polyspace.

So I think, very recently, I've been-- like I'm sure Overflow or Stack Exchange is something widely read by most of us engineers. And very recently, when I was also going through some articles or some questions over here, I seemed to be coming across a lot of problems around debugging.

The first step to debugging is if we can-- somebody is saying that it all compiles fine on my computer. But I'm really unable to find the error. Someone is saying that reproducing that kind of an environment or reproducing the problem is the first step to debugging. Someone says, yes, we can debug. But for concurrency and other issues, it's not so easy.

And someone is saying that external data, which is created or referenced, must also be consistent, whereas on the right-hand side, you see that somebody has given up a very big story around debugging and how it became very tedious for him. And then we might see that here. and then one thing what the engineer had put up is one might see an odd value while debugging and fix it without checking what caused the value to get there in the first place, right?

So there are so many questions, which keep popping up. Developers are popping in questions every day around different problem areas. And we are trying to see how we can make their life easier by introducing advanced techniques in which you will be able to debug or effectively find a defect in your code. And you will be able to identify the cause of it.

So what is debugging? It is nothing but how we are going to be handling the fix. And it's about all about identifying the error. It's about identifying the error location, analyzing the error, proving the analysis, and covering any lateral damages, if any, right? So to do so, what do we do?

I mean, just look at that, something which I picked it up from Reddit. So it is on the right-hand side. So it's a firm where they're telling that whatever tactics you're using to debug-- maybe you want to take a walk. You have developed a piece of code. And there's something not going well. So maybe you take a walk or talk to a rubber duck. Or you want to Google.

And mainly, we would see the print statements every now and then, where debugging-- like to do some kind of debugging, run the same code again, again. And magically, somehow, it might work, right? And using breakpoints or whatever. So as developers, it's just a pun, so don't take it very seriously. So that's just representing how different things we take up in order as tactics for debugging, right?

So basically, the idea is around how we are able to identify the error, identify the error location, analyze the error, approve the analysis, and cover collateral damages. And what is making debugging complex is obviously the complexity in the code, which has been increasing immensely. Along with it comes various different issues, like our code is not simple, we have pointers in that. And then there are aliases. And then there could be-- it's hard to identify the track around the pointers. Then there are multiple procedures, which are involved.

There are so many things which we need to account as developers in order to identify what the data flow issues could be like. We have to also account the data flow aspects while debugging. Or when we're dealing with concurrent code, it's not so easy as well, right? So there are multiple factors which also add a layer or a dimension to our debugging, which makes it really difficult.

Then what tools do we have for developers such that we make it quite easy for anybody to understand the code or for anybody to kind of know what best methods they can actually adopt in order to make their debugging very easy and effective? So there, we are introducing something called as Polyspace, which is nothing but a static analysis, which is combined with the formal method-based verification, which will help you effectively debug and also enhance the quality of your code.

So with this in mind, let's now jump into what is formal methods. So formal methods is nothing but a technique for specification development and verification. So basically, formal methods can be applied to various different parts of the software development lifecycle. But here in Polyspace, we will be using the same for verification of the software.

And there are various different techniques. So if I have to simply put, formal methods is nothing but a mathematical analysis of your program. So your program is mathematically modeled in the backend. And it is solved for certain equations. I would simply put it that way.

And then it'll help you identify the correctness of your program or prove any kind of errors or absence errors in your program. So there are various different techniques also inside this. There are model checking. Or there is abstract interpretation. But with Polyspace or with any of the methods which I'm discussing further today, it will be about the abstract interpretation, which we are going to use, and mainly for the verification of the software, which we are going to take it as a newer dimension in order to see how developers can benefit from this.

And why of all static analysis? Now, as I mentioned earlier, we are going to be combining the art of formal methods into static analysis. We would be marrying these to in order to get the best benefits via static analysis. If you look at this picture, so this represents a design space. And inside the design space, what you see as these star marks would be nothing but your test cases.

So whatever you design these test cases, you develop with an objective of identifying the bugs. And that's how you develop these test cases. And what you see on the edge, or the boundary, represents the edge cases, which are hard to reach states, often not met by your test cases. So what the static analysis allows is it allows you to reach these states that is the edge cases, unusual runtime scenarios. And since static analysis does not require any kind of special additional things like need of your hardware or any test instruments, you can easily adopt this at early stages of your software development.

And we can run it as often as possible and as early as possible in order to reap the benefits of consistency. So that is why we use static analysis. Now combined, both of them gives us a very powerful method in order to effectively debug and also identify the defects. OK, so this is just talking about abstract interpretation, which can be used to not just debug, but also prove that a software will not exhibit certain runtime errors.

So now, let's look at what comes out as the best of both of these worlds-- that is, marrying the formal methods along with static analysis. So let's just have a look at this. So in my ID, what I'm doing today as a developer, I'm developing a simple code. So I'm calling it as new position, a small function, which I'm developing today.

And I'm taking the inputs from two sensors. And I'm passing two parameters into it, which is into the new position for sensor position 1 and 2, which is minus 100 and 100. And then you see inside that, I have various variables. That is x, y, actuator position, and then using magnitude as dependent on that position. And y isn't entirely dependent on magnitude, so on and so forth. And I have various different arithmetic operations going on inside this function.

And now, given this function, now the very first thing as a developer, what I could do is I will probably just go into this. And I will hit the Debug command. Ah, now I see that the--

[AUDIO OUT]

Can you try it once more?

Yeah. Are you able to hear? Please give me a thumbs up if you're able to hear now. OK, fine. Thanks. So now, I see that there is an arithmetic exception, which has happened over here. What I will be doing is-- I know that there is an arithmetic exception over here. And as a developer, I need to identify what is the problem.

So I see that obviously there's a division operation here. And this could be moreso a divide by 0. But anyway, I'm not convinced with that. So I'm reading some breakpoints over here. I'll be introducing some breakpoints. And then I'll be debugging this code. Am I audible? I think others are able to hear me. So can you please check?

Yeah, I think I'm hearing a lot of yes from here. So I think a lot of people are saying that they're able to hear me. OK. So now, while I hit into the breakpoints, now I step into this code. And then I will try to run this program. And with the Debugger mode on, I have opened the Debug Console, so you can see the sensor position 1 and 2.

Now, you can see the values of x and y. As I keep on populating the values of x and y, they are changing. And now, into the watch window, I have actually kept x divided by x minus y, which I place the arithmetic exception. So I'm more keen to see what is happening with this.

So now, as I keep on moving this or I keep on moving through the breakpoints, now I would see that this break down-- this breakpoint has to overcome the iteration of 100 because I have a while loop, which is kind of going 100 times. And I'll have to keep hovering this over and over again till I'm going to exit this why loop. And then I have to actually see where I would be getting this exception.

So while I do so, a loop of 100 doesn't seem easy. But what I would do is now I would just invoke the Polyspace and ask it to run this program. And here are the results. So I see that there is a red mark. And the red check represents that there is an arithmetic exception. It is just pointing to the same arithmetic exception. And there, you see on line number 20, I see that x divided by x minus y.

Yes. So many of you have replied that it is because x and y are equal. And that definitely we can actually see from this over here. As I keep hovering my mouse over the different variables on the screen, I see that there is an arithmetic value or a range present over there. And this range helps me debug or understand my code much better because here I'm not literally going to be iterating those 100 iterations.

But this is nothing. But it is going to be an abstraction, I would say. The abstract interpretation is just going to be abstracting some real needed values. And then from there onward, it is going to construct some ranges. And it's going to propagate through these ranges. So what I mean to say is this is simply a mathematical analysis, which is going to let me do the analysis mathematically without me having to--

Can you zoom in maybe?

Yeah, can you just hold? Yeah. It's zoomed on my computer. But just give me a second let me help Zoom this a bit. So let me unshare and share, OK? OK. So right now, I'm sharing my screen. And I hope there is more clarity into this. So if I see that, while I was looking at this, there was an exception. And that exception was very easily prompted by Polyspace for me because if I look at each and every variable over here, there is a number allocated.

So I see that magnitude is, again, dependent on sensor position 1. And that's how even y is constructed because it is dependent on magnitude. And internally, it is dependent on sense of position 1. And then as I keep iterating over this, actually, it doesn't take that while to iterate. This is just an abstraction of this loop. And therefore, it has constructed some range into it. I really do not have to go over 100 iterations.

So that is the beauty of abstract interpretation or formal methods. Now, I have a range associated with it. And simply, when I go over here, I know that the values of x and y, they are being associated with 100 and 100. And that is the reason why there is an exception. And now, how I can change this or what I can do? I can really compute by looking at the other values. And that's how it is easier for a developer.

Now, assume that it's not just 100 loops. Let me just iterate this for another two more zeros, which is 10,000. As a developer, would I want to really debug this 10,000 iterations? So it would be really hard for me to do so. So I'll just increased that to 1,000 maybe, 10,000 maybe. And I can even change the values over here. Whatever input I'm giving, I can easily change these values very quickly.

And once I give this and I give it a run, so it's as easy as it gets because I don't have to enable any breakpoints here. I don't have to enable any kind of watch window or anything. It simply allows me to just statically give the code to Polyspace, and then run. There is a question by someone asking what does this black dot represent. Let me come back to it. So I have the solution now. I just increase the loop size to 10,000.

And you see that I've changed my values also to minus 10 and 10. So if you look at this, now I have an all green. So just have a look at this code. So I have iterated 10,000 times. So when I hover over these black dots, these black dots will give me the range of the occurrence of the variables. So if I look at actuator position, now actuator position is going anywhere between 2 to 10,000. Actuator position-- again, after incrementing, and now value of y is changing from 2.

As a resultant value up to post increment, it's going from 3 to 10,000. And the x value is going all the way from 3 to 10,000. So while I come back over here, I see that my denominator is over here. So we have one value as 10,000. The other value is 10,001. So always there is a difference of 1 between them. And that is why there is no divide by 0 happening over here. So what I simply did is I also changed the values to minus 10 and 10.

Now, the developer need not have to rerun anything. He just changes the values here. He changes the iterations. It is as easy as it gets without any hassles of introducing any breakpoints, or any debugger, or anything of that sort. So life gets much easier. Now, let me do one more thing. And someone also asked me, what does the gray zone represent? So let me go back over here into the dashboard.

So now, I see a gray zone. When I hit a gray zone, that means it's an unreachable area. So when I hit this, it prompts me to the unreachable area. And if I look at this, this code is being shown as gray. That is, the if is being shown as gray. So that means if section of the code is unreachable because the if condition is always evaluating to true. Now, how am I going to say that this is evaluating to true when I hold my mouse or move it it over the black dots again?

That's something of interest, where people have asked. Now, if I hold over here, you will see that the left-hand side computation is 100. And the right-hand side is 43. So no matter for whatever different reasons, this value is always positive and greater than 43. That is the reason why this condition is simply dead. Now, there's someone who was asking me why you change the sensor values. I am here representing-- or I'm trying to show you that you can manipulate these values right over here in the static analysis.

Given that you have various different conditions in your real development, you can change these over here. And also, suppose if I don't want to give any values at all. So let me disable this. And maybe I want to test this code for all the values of the data type. Then I will remove that, giving any values or supplying any constraints to sensor position 1 and 2. And let me run this code. Now, by doing so, what happens is-- let's see what happens in a minute, when Polyspace will be able to run this analysis for you.

So I simply don't want Polyspace to take in any values for the sensor position at all. So what I mean to do is I want to check it for all sorts of values. Now, this is the resulting. I already introduced you to what is red. Red means there is a runtime error or there's a problem, critical defect, which you need to check. I already introduced you to what is gray. That means these are unreachable areas. Now, you are seeing two-- one new color, which is orange. That means there is a probability of runtime error. And of course, green means everything is safe and fine.

Now, when I click on this, this shows me that, in this particular code-- so if I enlarge this code for you, you'll see that I have now stopped giving any values in terms of sensor position 1 and 2. So since I'm not supplying any value, sensor position 1 and 2 are now taking the complete value of its data type. That is the Int32. Now, given that if I'm testing this code for the entire space of Int32, what will happen to my code?

So if I hover over here, then I'll be able to see the range computation. And slowly, when I come back to this area, I will see that my resultant values will go all the way from minus 10,000 to 0 and from 588 to 10,000. So that means there is a chance of this denominator going to 0. And there are also chances where it might not go into 0. That's the reason there is also a green zone here and also a red zone. Together, it is represented as orange because there is a probability of runtime error here.

So the beauty of this is you are able to test for the robustness even without applying any constraints to your application. So this way, your procedure is now tested for robustness. Now, I know that there is a chance of 0 being over here. So it might be, as a developer, it is for me to ponder over and think-- if my sensor position values, whatever values I constrain, is it really going to be robust enough? Or whatever designs I've made, is the design logically correct?

So with this, it is very, very easy for us in order to debug. And now, not just that, I already talked to you that Polyspace not just-- I mean, it also solves a lot of other complications around debugging, which is like where we said that debugging is becoming very complex these days because of various different issues. And one such issue where I was already speaking was when I was telling you that there are pointers or where there are so many other issues which are coming into picture. Then how is it that Polyspace will be helpful for me?

So now, if we look at-- if I just hit over this, now you'll see in this code there are a couple of instances where a pointer is being used. Now, if I hover my mouse over that pointer, Polyspace is able to tell me what is this pointer all about. So is this null or not? What is the size it is pointing to? And what is the buffer allocation into this pointer? If the pointer is pointing within the boundaries or it is going outside the boundaries, is it a global or is it a local?

So Polyspace is able to let you know a lot of things about the pointers, even without looking into various other aspects or just statically giving you more information. So for example, again, if I have to look into more of what Polyspace can offer, not just giving you some range values, but going even beyond that. So if I'll have to look at instances where there is usage of pointers or anything, similarly, you have full-fledged information about the pointer over here.

Now, it is also telling that this pointer-- if you see in the bottom line, you can say that the pointer may point to the variable or field of the variable tab. And now, let's see. And if I go over here and say Go To Definition, it directly takes me to the definition over here. And this is a global variable. So there is also a Global Variable window, which will tell me that-- where all the global variables are connected. So you see that was a global variable to which the pointer was pointing to.

Now, it also accumulates all the functions which are involved with this point-- with this particular array. So I would see that init globals or initialize current data are writing into this value. And maybe interpolation is reading from it. And overall, it will take a value of 0 or 12 within this program. So then when I go back to this instance and I see that this particular value-- now, you see found is equal to 2 and items are equal to 1 are represented in a somewhat gray color.

If you're able to distinctly look at these colors, you will know that these are grayed out. And for the reason why it would be grayed out, now Polyspace is also telling me that this if condition is always evaluating to false. Why is it evaluating to false? Now, again, I'll go back to my black dots. I'm going to ask my black dots if everything is fine here. So when I look at this, I would see that the first condition is satisfied, whereas if I look at the second condition, I know that the global variable is fed the value 0 or 12 over the course of program, which is never greater than 16.

And that's the reason why there is a dead code here. This is a typical data flow issue. So now, we are able to look at something like a data flow issue. We are able to go through the ranges. Now, if we have to look at something like shared data analysis-- so if we have a multitasking program, then we can look at what is the state of the global variables here. For example, there is a global variable called SH4.

Now, if I maximize this and look into it, now there is already information from Polyspace saying that this is shared among several tasks. And who are the tasks where it is shared? You can see the proc tool, server 1, server 2, deregulate. These are all different functions. So if I hit a button, hit on them, it'll directly take me to that particular function. If I say server 1, it takes me to server 1. If I hit deregulate, it takes me to deregulate.

So this way, it is able to tell me who are all the tasks who are sharing this and what is the potential problem. If something is protected, now here also, if you say-- like in concurrency or in multiple tasks or multiple tasks, you can see that this is being written and read by two different tasks or three-- two different tasks are writing into it. And one task is reading from it. But there is no problem over here because it is telling that it is protected.

Why is it protected? Because it is enclosed by some critical section. So if you want to look at it, then maybe we can hit on these functions. And we can have a look whether these are being protected or not. So it will directly take me to the code. And if you see, there are critical sections, which are enclosing this particular variable. And these variables are colored green in color because they do not have the problem of being a shared-- problem of being corrupted because of sharing.

These are all shared resources, which are again protected, so on and so forth. So if we look at all these different things, we will be able to understand the control flow as well as data flow. So if I hit on this, it will tell me what functions they are calling and what functions they are calling from or who are its colleagues. Or even if I just simply go to any of the problems and then I hit on this button, it will give me the course the program, like it was called by main, and then called by another function-- call ID, whatever file it is.

Then it was called by pointer arithmetic. And then it led to an illegally referenced pointer. So there is a clear way in which it communicates what the problem or how the problems's root causes-- or what the problem's root cause is, what are the different range values, how you can navigate between this code.

All in all, these things are going to make your life easier as a developer to understand, to debug, to know where the root cause is, and finally cover any sort of damage which could potentially happen because these are all critical bugs. All right so let me unshare. I've just unshared my screen. But I'll be sharing back my screen. So let me know when you're able to have a look at the screen back, all right?

Yes. So you're able to see my screen? And there you are. Yes? So we have seen that these are all different challenges we have around the debugging. And of course, we don't need any tests, hardware, or instrument because it is statically going to analyze your code. And we are going to be analyzing the source code statically. And there are going to be no false negatives. Or we are going to ensure a sound analysis that no defects are going to be left unchecked or undetermined.

So that's where debugging with formal methods helps us identify the error and identify the error location because we haven't even traced and sourced code navigation. Then analyze the error because we have a data and control flow-based analysis. And then there is a mathematical proof to prove the analysis. So it is simply replacing your peer review and automating it, and then obviously covering the lateral damages because we are identifying all these critical defects in the development stages as well.

So that brings me to conclusion that Polyspace is a tool-- that is, Polyspace Code Prover especially is a tool mainly for debugging, triaging, understanding, or proving the absence or presence of runtime errors. It basically looks into a category of 33 different runtime error issues, which are listed over here. So they are mainly identifiable by Polyspace Code Prover and can be used for robustness.

It can be used for deeper analysis of some of your critical software. And it is also used for getting credits for a lot of different standards, which we will discuss later. Or perhaps, you can write to us if you are really interested in understanding about the credits around various different standards. So that is what we spoke about Polyspace. So now, you can see that somebody was asking me what these different colors are.

And the color representations are given here very clearly. Along with that, yes, there were also people discussing if MISRA or something is of an interest. Or is that something which is also handled by Polyspace? Of course, yes, because we do understand that, under the static analysis, there's a lot of things which we can offer. So one such thing is also around how we can actually extend this for people to even do a lot of other analysis, which I'll be speaking to in a bit.

So now, I would like to just tell you that we already have our poll open. So in the poll, we have various different questions. So right now, we are on the first question. This poll is open entirely throughout the webinar. So now, I request all of you to go to the first poll and answer them. I will not be waiting for long on this poll. So you can take your pace and answer these questions as and when you can get time. So right now, if you can complete the first poll, it will be really helpful.

So please feel free to answer this. And I request that all of you answer all of these polls by the end of the webinar. Or if you feel that it is distracting, maybe by the end of the webinar, you can finish this. The poll window is open for you, so you can answer it in that. So this is just a slight flash is just for you to see which question we are in. OK. Now, in the interest of time, I'll be just moving. Any questions, we'll handle at the end. And we'll also get back to you on the questions.

So we are basically discussing on how we can left-shift our verification by using the static code analysis because this is going to help us test every time-- test early, continuously. And we can test it every stage. We can test everything because somebody is asking me, does it always mean a main? No, it does not need a main always. So we can test anything and everything over here. So we need this prevention, which is better always.

So that's why we are emphasizing a lot on how static analysis can help you left-shift. Now, typically, let's look at a situation where a developer is developing a piece of code. And he or she has written that code on a Monday morning. And it was a very simple function. And then she thinks, OK, that function is over. And now, she can concentrate on other activities. And then what happens?

She has submitted the code into the source code repository. And then maybe we have a mechanism in which we do some analysis overnight or something. And then the next day morning, she thinks, OK, I'm all done with the code. And now, I'm all free. But what she encounters is something different. She gets a main saying that there is a problem in the analysis. And the next day, she did not expect that there were so many defects coming in from a simple piece of code.

So I'm sure that all of us would have somehow gone through these situations as developers because we might have thought that things are easy and done and we are fine. But something keeps coming back. That is true. So if you look at another survey, it says that at least 13 hours is needed for any developer to fix a backlog, which is a minimum time. So even a simple function can appear very simple for us. And we need not look. But there could be some real issues which are hidden into it.

So this is something by a survey, which I'm sure is something agreeable by all of us because, as developers, we might not be consistent. And however good we are, we are still human. So there are problems which we are always encountering. So in this case, let's look at a very simple thing-- what this developer tried to develop. So she just tried to develop this small piece of code called debugging a bug, which is taking a character value as minus 1.

And if you see, what happens is she's returning device-- I mean, she's returning this value, what you see over here. So let me run a debugger on this program. And it's a very simple four-line code, not very complex. But she thought there is nothing in this. And then when she hit the debugging, so what actually happened? So again, she has encountered a numerical exception over here.

Now, what is the problem? Now, she wants to understand, as a developer, what could be the problem in these lines of code. So again, she will resort to setting some breakpoints, by using some watch windows, where she is going to watch that particular expression, where a is less than 0. So what might be the problem over here? So she is just going to go through these. She's going to step into that particular function. And then she's going to be looking if she's able to find the problem.

Now, she sees that the device is having some junk value. But yeah, of course, as she initializes, she sees-- she watches over the local variables, which are populated, the values as it is. And we see that the if condition does not go through at all. So that's correct. A couple of you have answered what is the problem. But this is a very simple one. So what is actually happening, in this case? So let's see what is happening and how you can actually resort to something like Polyspace.

So 3 gave out a result. And it showed you that there is a problem over here. And what would be the problem? Again, I'll go back to Polyspace's mathematical expression. And I will try to hover over different values. And now, as I keep hovering over this, a scalar division by 0 is because the divisor is still 0. And this loop did not go through. You see that the left-hand side is associated with 2.32 minus 1, right?

So this is simply because-- now, because of the conversion of Int32 into unsigned Int32. So that is where the value of minus 1 was now wrapped up to 2.32 minus 1. That's a very simple thing, which we did not think. And then it led to a divide by 0. So as easy as it gets, as simple as it gets, any big cod, small code, everything is welcome into Polyspace. So there is no barricade on that.

And now, these are several different things, like runtime errors or very simple things which were neglected and caused catastrophes. Some of the examples are the Ariane 5, which led to an-- which is called as an expensive firework. Of course, it's a pun. And then you look at Therac 25, which led to fatal overdose because of some concurrency issues and other overflow issues. So these are some things which are not simple things that all these critical defects went ignored into the production programs and led to all these problems.

So as developers, we can ensure that we don't wind up in such things and use Polyspace or something as such very early on. Now, as we are already discussing not just about the numbers and about critical defects, we also have Polyspace supporting you into large number of things like Polyspace Bug Finder, which supports you into identifying 300 different defect categories, coding standards around safety and security, like MSRA, CERT-C, WE, AUTOSAR C++ 14, et cetera.

So the 300 different defect categories are represented in the red zone. And they're all categorized under the categories listed over there along with that, there are also matrix which are supported by the Polyspace Bug Finder. So Polyspace Bug Finder is another tool for you, for the rescue in order to stay compliant to coding standards and also identify various different defects. Following guidelines or standards is really important because even when we look at a lot of security issues today, so they could be stemming out of very simple problems.

For example, over here, there is a function, which is printf, which is being used over here. Now, had we enabled Polyspace Bug Finder, it would have immediately given you a feedback, telling you that this is a dangerous standard function because a buffer overflow can be seen with this usage. So instead of that, because of the risk associated on buffer overflow, which is, again, a backdoor entry to a lot of cybersecurity problems, Polyspace would tell you that, instead of that, please use something else, like snprintf or something else.

So first thing is to identify the vulnerability. So we have identified the vulnerability, as close to development stages where there's an immediate feedback to the developer. And as soon as he sees and flags this, he will be able to arrest it and avoid a lot of other problems in the future. So such examples are Jeep Hack, where, in very simple thing, my random number generator was root cause, where it led to a lot of problems. Had they seen this at the development stage itself and arrested this, they could have avoided it.

And similarly, you have the OpenSSL Heartbleed, where, again, there was a mismatch of the variable length in the memcpy function. And that could have been done. So all these things are simple things. How do we use them in development or in our early stages of verification? We could have actually arrested issue which has later on become issues, right?

So now, we have a lot of misconceptions, as I told you, that many times, we might be using the static tools at the end of our verification, which is not true. That is where we are emphasizing that we need static analysis. Even though you do dynamic analysis, it doesn't stop you there. So I already stated some examples where, by doing simple static analysis, we could have avoided a lot of problems, which could have turned out to be like mishaps later on, like a Jeep Hack or like OpenSSL bleed, or like even the Therac 25, where the overflow caused a fatality.

So we can arrest all these things by not treating static analysis in the end of your development, but bringing it very close to our development cycles. So one thing which we are concentrating over here is pre-submit workflows for quality code. So pre-submit is something your workflow, which is existing within the developers before they submit their code into the source code repository-- before this itself, we have a lot of things which we can do.

For example, I already told you how we can enable Polyspace Analysis or Code Proving for Debugging. That could be one step. And the second step is also how we can actually include this in the developer's environment by plugging this in into the IDE itself so that we do not-- we catch most of the defects in the IDE stage itself. And 3 is how do we keep any kind of gatekeeping. Or we do some kind of a gatekeeping before source code repository submission.

That is, before we check in our code, how can we do some kind of an automation so that we do not bypass any kind of static analysis and we stick compulsorily to it? So these are some things which we would also be discussing. So before that, the second poll is open. I mean, all the polls are open again. So please, this is a reminder that, if you have time, maybe you can just go and do the second poll, all right?

And now, moving to the next part, which is Polyspace can be used as an IDE-based solution, of course. There are ways in which we can use Polyspace into the IDE, for example over here, instead of debugging. So I have Polyspace integrated into the system. So you have Visual Studio Code representation over here. But it can be done with other IDEs, too. So now, Polyspace, instead of going in elsewhere-- so I can just click a play button or a run button over here within the IDE itself.

Or upon a resave, I can run it. So I can have space running it on the translation unit, which I'm running. So right now, debugging.c is being analyzed. Once it is being analyzed, it is telling that it spawned 20 unjustified Polyspace findings, 20 findings on this simple 5 to 6 lines of code, of course. So now, if we want to go over this, probably I can click on each one of these and get more information on what these are. Or they're actually also annotated on the code base itself.