 So, today we study about static analysis aspects, so before that I will try to recap the aspects before that we will try to recap so what we have studied in the earlier static analysis session so we continued about static analysis control coupling and data coupling data flow analysis we know that the program path worst case path will be exercise in terms of the programming structure and all that in the control flow and in terms of data coupling and data flow we consider the use of the data always going to be interfaced between two different functionalities or procedures and reference the variables define how it is being typecasted double variable anomalies whether same names are used in local etc all this will be analyzed statically with the help of the program so basically static analysis will be done during the unit testing stage or during the integration testing but the emphasis during testing is on project standards and code as per that it needs to be analyzed against and such as no go to breaks in all procedure size all this will be analyzed to see that the correct program and the program is within the safety definition of the unit what is being implemented similarly unused items such as unreachable code or variable will have to be removed that also will be analyzed during the static analysis similarly the architectural aspects of the program such as the designs level also will be inspected for the control flow and the data flow so there we see how the parameters are flown between different functions and the how the function is going to flow so control coupling and data coupling can be done during the integration mostly the integration could be software integration or hardware software integration so next one we had gone through some of the static analysis tools such as understand for cc++ or ADAPR or SKY tools poly space coverage QSE can that are ADR test but all this can be used for static analysis basically they provide the call to the user of the variables the complete report line code the make a way complexity what we have studied and of course the inbuilt tools such as misra tools will be part of the ID the integrated development itself so we can run through the tools such that it generates the report that what are the info type errors or the what are the warnings or the violations that we have in terms of misra rules similarly we have logiscope rule checker PC linked likewise so also we had gone through a sample snapshot of understand for cc++ here you can see the invocation so with the help of invocation of different functions we can understand the control flow similarly the variables unused to objects all that is analyzed with the help of this tool the other tool is the check marks so one sample report also we have seen in terms of how deep the control flow can go from left to the right most you can see the various procedures or the functionality for the called so typically this is the tree call tree that will be produced during the static analysis as part of the static analysis we also do the WCT and DCT DCT stands for the best case of execution more time and WCT stands for worst case execution time so basically it provides what is the worst possible execution time on the worst possible execution path that system can take during its execution so that it will be analyzed against the stringent of the performance of the implemented embedded system program so that also will help in terms of how much we can optimize which functionality we can optimize in terms of comparing various units such as algorithms any closed loop control systems all this will be measured so very important aspect of this static analysis that WCT control flow and data flow have to be measured so additionally for the timing requirements so memory requirements and all that we use logic analyzers oscilloscope and any support tools such as emulators, kinetics, emulators etc also there is another aspect of static analysis that can be done is with the help of a test hook or the test code that will be inserted into the software and there are software profiling tools which will help in terms of analyzing the call stock, stack memory, stack analysis, stack overflow, all this will be done with the help of the inserted code so that is also a part of static analysis here we can see an example of static analysis the relationship between WCT, VCT and possible program execution time over the recant side which runs the time and we will define the possible execution time in the center and the tighter execution time of the safe execution times likewise so there is a boundary analysis we call it so all the top ones will be done as a pre-analysis and for the post analysis the static analysis will be done on the functions that are implied within the program in terms of flow graph, call graph and the WCT bounds it will produce so coming to today's session, stack analysis and stack overflow and stack overflow inside environments we will study about this okay so what is stack analysis we call as a stack which is a memory part part of the program which will be used dynamically during the execution of the program when there is a preemption or when there is a entry exit of different functions of the procedures the stack will be used for the purpose of saving the state and retrieving the stack, stack is a memory part of the embedded program which will have a store or save and retrieve that will be keep on doing over the execution of the embedded program such that there is no loss of data during preemption, preemptiveness basically this will help in preemptiveness of sub functions from the main functions or the sub functions from the main functions main to sub and in order to reserve some of the variables during this execution this will be used main to sub and reserve the space for storing the state or temporary variables whatever it is depending on the state where the main booking was used so it needs to save the current state and the flow of the variables that it is using and once the subroutines calls are done going back to the previous routine all the shared one will be retrieved and the execution will continue. So similarly we have ISR interrupt service routine so what it does is whenever there is a ISR or it is also called as a exception so what will happen is the ISR takes the priority and before ISR invoking whatever the preemption happened on the routine or the person it will save the state of that routine in terms of the states the variables or the program counter where it was then once the ISR is written that state will be retrieved back and the execution will continue. So for this there is a dedicated state that is called stack so this stack has to be defined during linker we know that compilation and linking is two aspects as a result of linking we know that object points are produced along with the map of the complete embedded system program so what we do there is a linker file which defines the all the memory basically but in particular the stack which we are of interest now so this stack basically will be defined in terms of how much the program is going to be basically based on the complexity and the level of nesting the subroutine calls the all these matters so based on that the stack will be defined it could have one K to K whatever it is depending on the complexity of the program so the stack will be defined and at any point of time the stack needs to be within the certain range that means so what will happen is so suppose let us assume that we have a stack and the total size is say is a lower bound this is the upper bound we have say one kilobytes so what will happen is this area will be used utilized by the program and the stack will usually grow from the lower to higher side usually so whenever there is this event like subprograms subroutines or sub functions are executed or the retention from the ISR this stack memory will be used in order to save the states and the variables inside the stack and it will start saving from lower to higher likewise till the last phase so we have to make sure that while doing the linking we will allocate a sufficient stack such that at any point of time it will not overflow that means the stack cannot go beyond the allocated memory so that is what we have to ensure how this will be done there are different tools and techniques that are used but this will be part of the static analysis so that is what the crux of stack analysis so basically we need to see the stack program how much it is allocated and the stack users will be calculated based on the embedded application how much size is going to take okay so stack analysis stack memory has to be allocated statically where the programmer as I said during the compiler time this will be allocated under estimating stack usage can lead to serious runtime errors because we do not know the behavior of the program because it is not able to save because already the stack memory is over flown and it is not predictable so definitely we need to have a buffer of the stack at any point of time during the program execution so it is difficult to find the stack issues over estimating stack usage means we know that too much memory we have and we use a very less space of stack is also of noise so typically in the embedded industry they suggest the designer to have at least 50 to 75% of usage so that there is a 25% of stack as a buffer so that is that standard they imply is about 25% of memory sorry even memory also they recommend like that stack usage should be stack should be reserved is what they specify so we should not have a over estimate as well as over running the stack that is what is very important and the stack analysis calculates the stack usage of embedded application the analysis results are valid for all inputs and each task execution definitely each task we should be knowing how much it is going to use the stack so the results will valid relate all this so basically stack analysis calculates the stack usage of embedded application stack analysis can directly analyzed on binary executable yes we know because binary executable is the one which will be running throughout the embedded software execution exactly as they are executed in the final system stack analysis not only reduces development effort but also helps to prevent runtime errors to stack over for definitely stack over for is one of the typical common errors that we have seen especially in the application field such as VCE VCE++ VCE but in embedded applications where we are not clear about where our program is going to go or where it is not clear for the designer to design how much to reserve and he would have defined a limited memory and definitely there is a chance that overflow occurs this is why because programmer knows about the program what he has developed but there are different things along with the program what he has developed such as libraries he could have used which he is not aware of how much it is going to use and there are certain assembly code he does not know how much it is going to occupy a stack and there are certain support functions or some third party hooks or code which he is not aware so those are the areas where VCE there is a stack overflow which I mean the chances of stack overflow is there so that needs to be meticulously analyzed that is what stack analysis is about preliminary the analysis can be done on the map files generated during the build process that means once we build after the linking to be generated along with the binary executable the map file the map file will clear it tell how much executable various start where is the end and all that so based on that we can analyze the stack that is about the stack analysis next one so there is a stack overflow problem so what is that mean stack overflow so we will study that depending on the programming language use on the implementation of the compiler various problems may arise in the event of stack overflow the problems manifest themselves as that means what are the problems that we are going to come across when there is a stack overflow so what are those a corruption of data if the stack overflow causes the software to write into a data location definitely we are going to have an unintentional write into a data location that can cause the corruption of the data a machine exception because there is a stack overflow adjacent to protected memory and we are trying to write either or access the code which are read only memory sort of thing definitely there is a unwanted exception for this then an unpredictable program execution that means the execution cannot be controlled if the corruption of data occurs and code addresses are corrected definitely the code can be have available we do not know the return addresses of a function can be corrected and return may be improper etc so definitely it is unpredictable and the fourth type of a which will be a software exception we have seen machine exception where the processor itself generates the exception for a internal exception which is predefined in this case a software exception the program contains code to check the stack if that is there then we have a software exception so basically the purpose of a stack overflow is to guide for determining whether software design should implement the protection of the ones who cope with the stack overflow basically it tells what is been designed whether stack flow is going to happen or not so this is very important typically in the industry where they follow standards such as D1 senate B so there is a D1 senate B guidance regarding the stack usage and stack workflows in the areas of code reviews requirement based verification however it does not cover the possibility that a data corruption occur and lead to stack overflow so that is very important dynamically when we execute to have this considered in terms of data corruption so the purpose of stack analysis for the stack or to provide details of specific aspects so which should be attended appropriately okay and so sometimes in different programs they will have a secondary stack as a additional buffer so secondary as secondary stacks are used less frequently they are useless and their use is typically under the control of runtime functions stack checks are often put in place to monitor the all secondary stacks that means there will be a piece of program already in the embedded software which can be monitored as well with the help of that the data that repeat reports we can monitor and arrive at whether the stack is fine if there is no overflow like this so it is something like a runtime check on the primary tasks primary stacks so and as well as the secondary stacks so this can be done with the help of review of the first code and the map file and workflows should be addressed by a requirement based testing as well as integration testing basically it is done during the integration testing it could be software software integration on the actual target this will be performed that stack analysis and stack over for the platform so analysis of the theoretical worst-case scenario helps to determine whether the use and implementation of top has been well designed in order to adequately manage data that needs to be handled to stack usage that means we know that the worst-case scenario how much to take what is the amount of time and memory it is going to occur so that also will help in terms of analysis of the stack so stack analysis of worst case stack will consist of identifying all the functions in the program and obtaining their stack frame size so we need to know all the and their stack size we need to collect it and stack size means stack frame size and also we need to determine the call graph who is calling who which function what is the call tree analysis so based on the determination of the call draft for each separate execution thread that means the different path independent paths that is nothing but a task so it stack analysis will be done and we need to combine all the data during this worst case stack size execution so this will be definitely done in the source code level so basically by counting the size of all the parameters so we don't need to do manually there are tools that will report the size so the size needs to be analyzed manually the next one is on stack workflow another set of information and unintended with stack workflow occur during the execution of a program for various reasons now we have seen the issue that is going to cause after the stack workflow what it can yield whereas what are whatever the reasons that we are going to have for stack workflow is as per the below so they are a hardware failure a software development failure sorry software development error that means it's not designed properly the hardware failure could be a memory is a word out or memory is corrupted or issuing the any of the parts that is not behind appropriately okay so and the other one could be an unintended software behavior there are software bugs which is intentionally not written and memory corruption we know that memory corruption could be hardware as well as software so other term is called single you so due to some program issue or something there is a one event that is caused everything in terms of spiraling different issues that could lead to a stack workflow that's what it means so this needs to be done by testing sometimes that means you need to analyze the behavior so typically they take the approach by filling the memory with certain memory pattern and to execute the tests which force the maximum usage of the stack so what will happen is so here is a stack and it is filled with a known pattern such as a a a a in the first line and f f f f is filled in the second line likewise it is filled so we know that the stack is filled here then we do some testing make sure that the testing makes the program rate the value of the stack into this area that means it is been over written by the stack data suppose this much is written or this much is written we know that the program that we have tested as utilized this much stack it means this much is still reserved so we read this portion we know that definite pattern is there and we are able to read it we know that that portion of the stack is not over written by the stack data so we know that there is still space available in the stack and the stack has not over flown or we know that how much stack is used so based on that analysis can be done so simple programs it will be easier whereas there is a complex programs so definitely we need to have a thorough stack analysis especially in level A software level A is the most critical software they use in the aerospace embedded software so in such cases when a stack workflow occurs during the execution of this level the consequences could be catastrophic as the software may be out of control we cannot predict definitely we cannot afford to have aerospace when it is flying having trouble of all the stack definitely that needs to be analyzed appropriately although an seo that is a single event upset is unlikely to be repeated it is a single time it is going to happen if a stack corruption or an overflow occurs due to a software error then given the same program state and input conditions the software will be repeated such a repetition may cause the recovery mechanism to be ineffective so it is very difficult to recover such errors which is spilled out of single event upset and followed by the workflow or the software error okay so coming to the next slide of the stack analysis we have ESA guideline ESA you know European aerospace industry so which have a stringent guidelines about quantifying or qualifying the embedded software for aerospace so their guidelines as per their guidelines the following four points have to be considered for stack analysis what are they analysis should be performed to define whether or not it is necessary to perform continuous stack monitoring based on criteria such as the software difficulty stack type the use of built-in monitors etc see what will happen is the typical embedded software in the airline industry or aerospace programs will have a monitoring functions that monitoring functions also will have a stock monitoring functions and if there are stack errors if it finds there will be a definite recovery from the stack analysis in terms of the reset or reporting whatever it could be if it is reaching beyond a certain likewise so that should be analyzed so that is what it means the next one if continuous monitoring of the stack is used it should be performed in real time that means if the monitoring part is there within the embedded software the critical embedded software piece then it should be performed during the real time that is what it means the monitoring mechanism example the monitoring of the stack pointer should be specified in the requirements that means this monitoring function also be a requirement because without requirement we are not going to have any program running on the target on field or will be delivered definitely as per the requirements that monitoring function will be developed and this monitoring function will monitor the stack continuously so this needs to be analyzed during runtime and that needs to be reported in the event of in the event that the monitor detects overflow the expected behavior means an exception or the should be specified and very good if there is an issue with the stack such as overflow the same thing needs to be mitigated within the program with the expected behavior with raising of the exception so that is what we can do that we know what is the issue for that particular exception it is because of stack overflow so to conduct runtime monitoring of stack overflow it is not a difficult one basically it is a implementable one it is additional piece of software but it is still worth because the criticality is very important so based on that requirements also will be made out and the monitoring policies also different strategies are followed basically based on the type of stacks I mean what sort of stacks they are having and it is a data stack or the program stack, executives level or counters etc so based on that analysis we need to be taken care so that is what the stack analysis of embedded program will be carried out especially in the aerospace industry that is what the guidelines talks about okay so with that stack overflow we are done so next we will move on to the coding standards we are done with the stack analysis now we are moving to the next aspect of static analysis that is the coding standards so this is a very important static analysis that is to be done though you think that coding standards is only for the coder or the programmer which is not true static analysis has to be done on the implemented code or the program that that embedded software has with the help of an independent reviewer whether the standards and the guidelines of the coding have been properly adopted during the programming phase or the coding phase of the embedded software is very much important we need to understand so what are the things that we are going to have in coding standards okay so coding standard defines a set of rules for programmers to follow unique language so there are levels of guidelines they give like it could be a guideline it could be a rule so in such cases where we have rules that has to be mandatory followed I will just try to write out guidelines will be there and we have rules which is very much mandated guidelines are something like not mandatory but recommended or optional something like that okay so that needs to be followed during the programming so programmer could have missed it or he would have ignored or there is a flaw while programming due to a last minute work or during a rework something would have missed it does not matter if it is a command or if it is a warming whatever this as part of the programming all this need to be stringently followed in terms of coding standards and the program may be working on the field very fine but definitely it has to have a proper way of maintaining the code in terms of coding standards that is very important okay the next one is a C coding standard can help keep bugs out of embedded software by leveraging common language features and development tools definitely there are number of tools that the programmer should try to use whether that program is having any issue in terms of coding rules where the variation is there basically because we may not see the hidden issues of the software which are laid out purely in the coding standards by following the coding standards there are language features which needs to be taken of course sample coding standard rules we can try to go through but it is not the scope of this but all we need to know is what is the coding standards how it is used and how it will be verified that is what we are trying to understand and it is importance that is also one of the thing okay so basically coding standards if it is followed properly it increases the readability and portability of the software that means the software is in a good shape to understand somebody somebody can read it easily it is so understanding that means the program is quickly analyzed the program can be quickly analyzed and understandable weight if it is implemented it is easy to use it or reuse it or whatever you want to put it to a different platform that embedded software or you can scale it or it can be maintained by different people or it can be tested easily unless so that is what the basic purpose along with the hidden bugs that could be there when implementing so it reduces the time required by individual team members to understand or review the work of peers that we know that we are going to have a different types of reviews and the reviews will be done independently that means if four people are there in a program who are working as a implementer that four people will be shuffled for doing the reviews of the implemented program that means person a will review person this code person b will review person a's code so likewise it is easier if and it is going to take less time if the coding standards are followed appropriately because the reviewers are quite aware of the programming standards or the coding standards so the typical embedded industry coding standards they use misera c 2004 which has about 100 plus rules 100 8 or something so that rules are categorized as guidelines and regulatory regulatory is how have need to be followed and guidelines are something like optional and basically in automotive industry they use this misera c okay so basically potential benefit of a coding standard people will ignore sometimes they do a prototyping rapid prototyping agile whatever it is but basically they need to have this process in place because the later part of the program especially the complex programs will be difficult if the standards have not been followed the earlier stage it is not going to cost much if the standards are proper and properly used by the programmer the following that is not a expensive one definitely is going to save basically because it is going to prevent a bug from creeping into the code so thus a key strategy for keeping the cost of firmware development down is to write code in which the compiler linker or the static analysis tool can keep bugs out automatically in other words before the code is allowed to execute better we follow the coding standards of course there are different sources of bugs in software programs but that is all the next level basically these bugs could have been injected or introduced or created by the original programmer but it could come out as a hidden issue or the bug in the later stages of the program when the program is running for sometime like months or years will then it is not revealed so it is difficult to fix if it is found after few months the program was developed today and the bug was found after few months definitely to fix such issues because readability or the coding standard has not been followed we do not know where the issue is typically the number of the number and severity of bugs introduced by the original programmer can be reduced through discipline conformance and certain coding practices especially something like placement of constants on the left side of each equivalence test that means we know equal to and double equal to the difference the programmer would have put one as a logic and other one as assignment so you would have missed so that could lead into a issue and coding standards following that will definitely ease out such issues the other aspect of coding standard is the commenting we know in CE we use this comments or we use this in adage this assembly so it is very very important to have a disciplined use of consistent commenting and stylistic practices that means we need to have a consistent comments like the comment should be so and so should be very brief and descriptive and it should be within the 80 lines all this have to be practiced properly so everybody in the organization can easily understand the meaning and the properties of the functions or procedures variables etc so there should be a meaningful name as well as the comments above usually above they put it in the C program it depends on what standards you want to follow it could be below or side of the program anywhere but it should be consistent and easier so that is about coding standards in this slide so we will go through some of the coding standards rules what the code should look like basically here you can see coding standard set of rules what code should look like like indentation rules they call it as example use start of straws pop they have vision straws pop is a famous C++ and C programmer basically he has written a book and he has put a indentation rule basically we can follow that and and code we can have typical specifying a subset of a long way that is better don't use new or throw in specially C++ predictability problems will be there typically specifying rules for commenting how we should be commenting every function must have a comment explaining what it does we know that there should be a proper description and comment for that function also the lines that are within the function the programming programmatic lines often requiring the use of certain libraries that means IOS stream STDIO printf all this will use it so to avoid safety issues we have to use it appropriately so we need to follow the rules our variations often try to manage complexity through coding standards that means the complexity we are going to dilute it in doing appropriate coding standards so that any of the complex program can be easily controlled often they fail and create more complexity than they manage so this is what the starts up programming rules talk about continuing on the coding standards a good coding standard is better than no standards we know that so this is also again a statement from stock stock is one of the pioneer in the C++ and coding standards so it could be a multi-million project or a multi-person multi-year whatever it is so without coding standards definitely we are not going to start it he says that way but even for a smaller project or any one month one project or it could be hundreds of lines we need to have a standard and the process that is followed a poor coding standard can be worse than most of us so that is also another thing that he is trying to tell C++ coding standards that restrict programming to something like the C subset do harm they are not uncommon that is all the typical issues so C++ coding standards could restrict the C usage because both are inclined together all coding standards are displayed so these are some of the facts that he is telling so good standards also people the programmer do not like to follow sometimes but the independent IVNV team make sure that they are all in place all the programmers want to write their code exactly there on there that is the problem a good coding standard is prescriptive as well as restrictive means it should be very crisp here is a good way of doing things as well as never do this that means you should tell both assertiveness as well as negativeness in terms of standards standards should specify both the restrictions or limitation or restrictions of what should not become what should not do and prescription also it should be telling what is a good thing to follow a good coding standard gives rational rules that means there should be a rational reason for every coding standards and rules with an example so that will make easier to maintain and review so that is what starts up programming recommendations and the aims or the goals of the common coding standards are as per below the reliability the portability maintainability testability reuseability extendability readability so these are the important aims or the goals of the coding standards i will repeat reliability portability maintainability testability reuseability extensibility readability so these are very important aims for developing the coding standards and following the coding standards okay so few sample rules we will try to go through for coding standards which are obviously obvious to follow for any typical embedded software implementation okay so what are those sample rules no function shall have more than you know why why because it is very difficult to maintain such program if there is a bug while doing the fixing the chances are that there could be a bug in another place so it is a creation of a new bug while fixing the existing bug so better to have a program having not more than 200 lines so ideally they said 30 50 lines or not more than 100 they say but definitely not 200 or more here what he says is 200 non-comment source lines not that complete program you can have a description in two three lines so for 40 50 lines you may end up in 200 lines but what he talks is about the EOC i think i told in one of the session about EOC executable lines of code executable object code i will again repeat some statement is there or the semicolon is one executable statement when this semicolon is also executable similarly for we have this flaw bracket and with the flaw bracket constitutes one executable similarly while so and so if else is one executable and what are the contents of this if else if is also a it will act as a another executable statement so likewise we cannot have 200 executable lines in the any function or 200 or more each new statement starts on a new line we cannot have something like semicolon followed by another statement like this which is a violation we cannot have multiple statements in single line that is one of the strict rule that has to be followed by three no macro shall be used except for source control that means we cannot afford to have macros in the program unless we have a source control that means we have a if def and if and if sort of a thing which identifiers should be given descriptive names that means the name should be very much sounding like what it is going to do what what is the intention of that particular variables identifiers here means local variable global variable or any object so we are going to identify so that should be small narrative or descriptive in terms of that particular signal it could be something like water speed so this is a variable name so we cannot afford to have ms people will write rm they let rs so it is not a good practice because even for the programmer himself may be difficult to maintain and execute so hence it is better to have a meaningful name for the identifiers so it can contain common abbreviations from when used conventionally x y y y x y y are descriptive but better to use number of elements styles rather than the number of elements like this so avoid all this single letter things instead of that if you want to mention number of elements better to use number of elements this way so that is what he says in his talks so we can have either way but it should be meaningful and understandable so what he is trying to say here is oh it should be capital it should be capital and n also can be capital such that it is highlighted properly and treated so type names and constants form with a capital letter that means the name of the constant or a type name always should start with a capital letter where you can see device driver starts with capital D buffer pool starts with the B similarly identifiers shall not be for only by case so we cannot have head and head once caps and small it is very difficult to maintain better head followed by something smaller do or it can read or it can lag whatever it is so better to avoid this kind of a anomaly that is what it says so all this have to be way I have put here is coding standards has to be in place and that should be analyzed is part of the static analysis by the independent tester that is what it means and by doing this coding standard static analysis the common objectives such as reliability portability maintainability testability reuseability extensibility and reliability these are achieved that is what the coding standards importance some more rules we go through identifiers in an inner scope should not be identical to identifiers in an outer scope for example we cannot define an inner scope variable with the same name but here you can see where is defined outside and inside also same name so you do not know what is going to be used we know what is going to be used but the user or the maintainability perspective it is not easier to maintain it so better to have a specific name meaningful name declarations shall be declared in the smallest possible scope variable shall be initialized it should be initialized definitely any variable we cannot just take care like this it should be declared should be used something like int where equal to 0 or depending on what initialization values need it should be used the next one casts should be used only one essential so unless otherwise is needed we should not be using the cast type cast basically code should not depend on precedence rules below the level of arithmetic so we should not have a dependency on the precedence so we should always try to see the implied behavior of the program based on that we need to have precedence rules defined here for example x equals a star b plus c here multiplication is the precedence followed by plus then b plus c will happen first and then that is not the way so this is okay so here in this case you see it is ambiguous and precedence is violated you can see parenthesis if a less than b or c less than or equal to d definitely is going to violate so rather than that you better do a parenthesis for this as well as this so that will avoid the ambiguity as well as some of the compilers what will happen the precedence would not have been defaultly defined so it may take a different way so to safeguard against those issues it is definitely better to have a precedence taken care in the program so that is to be analyzed appropriately these typical issues that I have seen in the embedded industry precedence rules have to be forward appropriately especially this is useful in arithmetic expressions as well as logical expressions increment and decrement operations shall not be used as subject expressions that means we cannot have index equal to v and within the array as an index that is being used as a sub expression so that increment might be overlooked so we do not know what is the right table behavior of this might avoid this and outside you do the pre increment so that is what the coding to coding standards sample rules is about okay so we will continue the coding standard rules coding rules power in the next session and also we will study about the reviews inspection and process in the next class so today we studied about tag analysis overflow coding standards and objectives of the coding standards so that is the end of the session for today