标签: static

static修饰三类，局部变量，全局变量，函数 修饰局部变量，作用域是此函数内部，其他函数不能使用，生存周期：整个程序，下次调用此变量，值是上次赋的值。 全局变量，作用域是定义它的源程序，其他文件不能访问：生存周期，整个程序 函数，作用域是定义它的源文件，其他函数不能使用

As a technology journalist, I get the equivalent of a postgraduate education reading good, detailed papers and reports, though some are mind-numbingly difficult. Knowing my interest in such papers, several software developers and tool vendors have independently referred me to "Quantitative Evaluation of Static Analysis Tools," by Shin’ichi Shirashi, Veena Mohan and Hemalatha Marimuthu, at the Toyota InfoTechnology Center in Mountain View, Ca.   In this paper, the authors describe the task of selecting the optimum code analysis tool for doing run time code analysis of software for use in Toyota's vehicles. Starting with tools from about 170 vendors of proprietary tools as well as a range of free and open source versions, they narrowed their choices down to six, those from Coverity, GrammaTech, PRQA, MathWorks, Monoidics and Klocworks to make their selections they used a complex methodology to first make their assessment and from that also derive a set of coding guidelines to help the company's development teams avoid defects proactively.   Readers of the report may disagree with the types of tests and metrics the Toyota team used to make its choices. Some developers I have talked to complain that despite the data-driven quantitative approach, at the beginning of their efforts the team made use of the qualitative and subjective judgements of a few experts they trusted. However given the number of such tools they had to evaluate, that was a choice they were almost forced to make. Even after limiting their choices in that way, there were many alternatives to evaluate and test, even after they narrowed their choices further by excluding noncommercial tools that provided no technical support, those that did not support safety critical applications, and including only those that supported the C language.   The paper describes how the Toyota team first created a set of test suites incorporating a wide variety of software defects that might cause problems in safety critical applications. They then tested the tools they had selected against that suite. Finally, because of the importance of driving buggy software out of the automobile environment, they went one step further: they used the data already collected to create several new metrics to further hone down the performance of the tools. For information on the various tests they used, they depended on several reports from the U.S. National Institute of Standards and Technology (NIST), supplemented with information from various tool vendors and users.   The choices they made and the process they came up with made it clear how many things can go wrong in a software design, especially a safety critical one, and how hard it is to pin things down. Drawing on every piece of literature they could find, they identified eight defect types that were important, including: static and dynamic memory, resource management, pointer-related, and concurrency defects as well as the use of inappropriate and dead code. From that they identified 39 defect sub-types, and from those they created 841 variations that they used in their tests. The methodology is about as comprehensive as any I have ever seen.     In addition to the defect code bases they created for their test suites, the researchers created an identical set without defects. The first code base was for evaluating true positives from the analysis results, while the second set without defects was used for evaluating false positives. The researchers also tried to keep the test suites as simple as possible while keeping in mind the nature of the automotive software environment, especially in relation to the use of global variables and stack memory. (The test suite benchmarks are available on Github .)   On average, the six static analysis tool finalists were correct in their detection of flaws in the code about 34 to 65 percent of the time, with Grammatech's Code Sonar ranking first. But a more important measure is how they ranked on various kinds of other tests. For example, on static memory defects, Gramatech's Code Sonar and the MathWorks Polyspace ranked highest. On pointer-related defects, PRQA ranked highest. On detecting concurrency defects, Code Sonar came out on top, while on numerical defects, Mathwork's tool did best. The report goes into much more detail, of course. Dry and matter-of-fact as it is, though, their report is worth going through slowly line by line because of its value to developers concerned about writing reliable, safe code.   The paper is a gold mine of information that I will refer to over and over again, not only for insight into which tools are best, but for the nature of the defects being hunted and the impact they have on overall software reliability. It is also valuable if you are interested in learning how to develop a methodology for assessing the complex trade-offs that must be made. Perhaps the most valuable lesson to be learned from this paper is the clear inherent message that if you are serious about detecting software defects, more than one tool is necessary, no matter how much the design team manager or the company accountant complains about the expense.

auto型变量：只能用于局部变量，局部变量默认情况下即为auto型。它会为变量在栈上分配空间。 注意：auto型变量不能用于全局型变量，因为全局型变量是在内存的 静态存储区（全局存储区） 上分配的空间，即堆空间上分配。 register型变量：寄存器型变量是将变量存放在寄存器当中，register只是请求寄存器变量，但不一定请求成功。 注意：1. register变量必须是CPU寄存器可以接受的值 （如32位机器，只能存放32位即4字节的变量）。 2. 不能用运算符获取register变量的地址 （因为register变量存放在寄存器当中，而是从内存地址当中取值，所以无法成功）。 static型变量：将变量存放在静态存储区，经常用于局部变量中， 当局部变量被声明为static时，虽然其的作用域仅仅是自其函数内部，但整个变量在整个程序运行过程中都有效。而且此static局部变量仅仅赋初值一次（在第一次调用此局部变量所包含于的函数时）。 注意：static的另一个意义是文件作用域表示符。（1.static修饰的全局变量的作用域只是声明的文件中。2. static修饰的函数作用域只是声明的文件中）, 下面举例说明上述几种变量使用出错实例(紫色部分为出错位置)： 实例1： #include stdio auto int a=0;  //auto只能用于修饰局部变量，它是用于将变量存放在栈中，而非全局存储区 register int b=0;   /*因为静态存储区的变量一旦设定，在整个程序运行范围内都有效。如果将好几个全局变量都设为register型变量，则对应的这些寄存器在整个程序运行 周期中就只能放这个全局变量了。占用很多个不同寄存器，而CPU的寄存器是有限的，很容易导致寄存器被使用完导致崩溃，所以编译器不允许将 register型变量放在全局变量区。*/ int main() {     auto int i=0;     auto int j=0;     auto int k=0;     printf（“%0X\n”，i）；     printf（“%0X\n”，j）； // 因为register变量存放在寄存器当中，而是从内存地址当中取值，所以无法成功     printf（“%0X\n”，k）；     return 0; }   作用域限定符： test.c #include stdio extern int test2_g; extern int test2_func(); extern int test2_ff(); int main() {          printf("%d\n",test2_g);        /*因为test2_g在文件test2.c当中是static型全局变量（作用域限定符），所以只能在test2.c文件中被访问。*/        printf("%d\n",test2_func());  //同上理        printf("%d\n",test2_ff());         return 0; }   test2.c   static test2_g=1;   static int test2_func() {     return test2_g; }   int test2_ff() {     return test2_func(); }

Many people may have encountered problems like this: Even though there isn't a while/for loop in the program written, the MCU would run in a dead loop (not responding until reset) eventually... If we use debug mode to run the program for STM32, we would see the MCU would finally go into the infinite loop in HardFault_Handler() ISR. Why is this event happening? The problem may occur when there is large array of variables declared like buffer in functions . A program is more likely to get this problem when the large variable is in a recursive function. To solve this problem, we have to know what caused the error. When non-static variables are declared in functions and there is an interrupt/function call they would be stored in the stack area. When the function call/ISR finishes, the variables would be loaded again from the stack area. If the variable is of large size, the stack may be full and cannot store the variables, causing the MCU to fail to execute anymore. There are several ways to solve the problem. The easiest way is to increase the default stack size : This method is not only working with STM32, but also other MCUs like LPC213x/ADuC702x (ARM7). Make sure that the startup file (e.g. startup_stm32f1xx_xx.s) is not shared with other projects to prevent affecting other projects. To do this, save the startup file as another file and replace the current startup file by the newly saved one. Fig. 1 The standard startup file of STM32 Medium Density Device Open the startup file and save it to the project folder. Then remove the original startup file and add the one just saved in the project folder. Fig.2 Removing the original startup file After adding the file, the icon will not have a 'key' on it indicating the file is NOT read-only. Fig.3 The startup file added, icon without a key Everything is ready, then open the startup file by double-clicking on the item. Then you may see the trick on the stack size: Fig.4 The stack size configuration in the startup file   Increasing the stack size like modifying it to 0x00000800 or 0x00000F00 may help to solve the problem. The MCU would divide more RAM space for the stack. The same technique also applies to other MCUs, with modifying the corresponding startup file. Fig.5 Stack size config section of startup file of NXP's LPC2000 series MCU (ARM7) However, there is a drawback - the area in the RAM for storing variables would be decreased - less variables could be declared (we would see the error during compilation)... But if the MCU has loads of RAM space, this method should be the best to the problem. Another method is to use global variables for storing large variables . This would not only help to reduce the stack loading, but also reduce the CPU's time to store the variables into the stack when interrupt/function call takes place. One solution is to use static variables , so the variables would not be stored to the stack. However, this method very probably CANNOT be applied to variables declared in recursive functions since each call to this function would modify the one and only one variable and may cause unexpected error (logic error occurred then ).