02計算機專業(yè)相關(guān)有關(guān)外文文獻翻譯成品c編程語言在增強故障檢測方面的擴展

1、<p>　　Extensions to the C Programming Language for Enhanced Fault Detection</p><p>　　DAVID W. FLATER AND YELENA YESHA，E. K. PARK</p><p><b>　　Summary</b></p><p>　　Th

2、e acceptance of the C programming language by academia and industry is partially responsible for the ‘software crisis'. The simple, trusting semantics of C mask many common faults, such as range violations, which wou

3、ld be detected and reported at run-time by programs coded in a robust language such as Ada. This needlessly complicates the debugging of C programs. Although the assert macro lets programmers add run-time consistency ch

4、ecks to their programs, the number of instantiations of this m</p><p>　　key words :CReliabilityRangecheckingErrorchecking</p><p>　　Introduction</p><p>　　It has been written th

5、at C provides about 50-80 per cent of the facilities one would want from a programming language.1 One of the missing facilities is run-time error checking. Errors such as exceeded array bounds, out-of-range data values,

6、and I/O exceptions, which are reliably trapped by the code generated by most Pascal and Ada compilers, go completely undetected by the code generated by most C compilers. Incorrect pointer usage and references to uniniti

7、alized variables can sometimes be dete</p><p>　　C will continue to be used despite its limitations, not only because the choice of language is often forced by external constraints,2 but also because many peo

8、ple have become addicted to the ‘worse is better’ approach to design and coding.1 Reliability and correctness are often sacrificed in order to shorten the production time of software. Our task is to enhance C in such a w

9、ay that reliability and correctness will be easier to achieve without removing the language’s addictive qualities.</p><p>　　One might claim that C++3 is just such an enhancement. Gabriel points out that C++

10、is closer to what we need than C and predicts its success.1 However, although it is possible to implement internal consistency checks using C++ classes, it still requires more effort than most programmers are willing to

11、exert for the sake of quality assurance. For this reason, the extensions which we make to C will apply productively to C++ as well.</p><p>　　MOTIVATION</p><p>　　The looseness of the C language h

12、as resulted in the emergence of classes of coding errors which are truly insidious in their frequency of occurrence and difficulty of detection. One such class of errors is array bounds violations. Although many believe

13、that out of bounds pointers are the primary problem in C programs, it is our experience that array bounds violations are more frequent.The reason why these happen so often, particularly in academic settings, could be as

14、follows:</p><p>　　Most programmers wholearn to program in a collegeor universityusePascal</p><p>　　as their first programming language. Those who know how to program already are nevertheless

15、 trained in the Pascal programming style.</p><p>　　Although Pascal allows significant flexibility in the indexing of arrays, the convention is to start indexing from 1. Furthermore, Pascal traps array bounds

16、 violations at run-time.</p><p>　　The programmer learns a habitual way of coding loops to scan array indices from 1 to N. The programmer also learns that he or she does not have to be extremely careful when

17、coding them since errors in these loops usually result in abnormal termination with a helpful error message showing the source of the problem.</p><p>　　When this programmer is forced to switch to the C langu

18、age, he or she has a strong tendency to scan array indices beginning with 1 instead of 0.</p><p>　　Unless the compiler or linker happens to place the array at the very end of a memory segment, so that a refe

19、rence to the non-existent ‘element N generates a segmentation violation or a similar hardware exception, the coding error has an extremely good chance of never being discovered.</p><p>　　The effects of an ar

20、ray bounds violation make sense only at the level of machine code. The identities of the data which are overwritten cannot be determined from the source since they depend on the arrangement of data in memory when the pro

21、gram is executing. There can be a different arrangement every single time the program runs if data are dynamically allocated; otherwise, the arrangement can change every time the program is recompiled.</p><p&g

22、t;　　The chances of the fault being discovered when the array is not at the end of a memory segment are poor. There are several subcases:</p><p>　　The data which are clobbered (unintentionally overwritten) ar

23、e never referenced after the clobbering occurs. In this case, the fault is completely masked.</p><p>　　The clobbered data have low sensitivity. The word sensitivity is sometimes</p><p>　　used t

24、o indicate the probability that a failure will result from a particular fault in the software.4 This probability was estimated in the cited paper using an analysis of code segments. For the types of faults we are conside

25、ring, the probability that a fault will be masked is sometimes more directly related to the overall usage of a particular datum than to any particular code segment. We thus feel that it is valid to refer to the sensitivi

26、ty of a datum in an executing program. It is our exper</p><p>　　(c)The clobbered data have high sensitivity. This is the exceptional case in which the programmer is lucky enough to have clobbered some data w

27、hich are vital to the continued execution of the program. Failures may be intermittent, but they are likely to be systematic. Even so, it frequently happens that the fault is never located. Consider the following common

28、 scenario. A program crash occurs. The programmer enters a source-level debugger and steps through the program until he or she notices an</p><p>　　Clearly the only case in which an array bounds violation is

29、likely to cause the program to terminate abnormally at the point where the violation occurs is the hardware exception case. Many compiler and hardware dependent conditions must be met for this mode of failure to occur. I

30、f the hardware platform on which the software is being developed does not support protected memory segmentation, we have an even bigger problem. Not only have we lost our best indicator of array bounds violations, we hav

31、</p><p>　　BACKGROUND AND RELATED WORK</p><p>　　In order to write robust programs in a fragile language, it is necessary to add code to explicitly perform the run-time checks which are needed. Th

32、ese checks are a form of executable assertion. Since it is prohibitively time-consuming and error prone for programmers to manually add assertions to test for the most common problems, it is preferable to have a tool to

33、add them automatically. Whereas inserting code to test assertions at run-time is an old technique which has been proven to be very he</p><p>　　A different approach which has been taken to improving C’s robus

34、tness is strengthening the semantics of the language without changing the syntax. Bcc2,8 appears to be the first utility to take this approach. Bcc traps a wide variety of probable errors in C code, including out-of-boun

35、ds pointers, dangling pointers, indirection through constants, misuse of null pointers, pointer arithmetic overflow and illegal array subscripts.2,8 Unfortunately, the resulting programs are said to be intolerably sl<

36、/p><p>　　By allowing extensions to the C syntax, we can trap classes of errors which are impractical or impossible to trap without syntactic extensions. For example, it is impractical to automatically trap erro

37、r conditions flagged by library functions unless there is a mechanism for the programmer to specify when such errors are to be handled explicitly or ignored. There is also no practical substitute for allowing the program

38、mer to specify the legal values for a constrained subtype (a data type whose se</p><p><b>　　ROBUST C</b></p><p>　　In order to gain acceptance, Robust C must not impose upon the progr

39、ammer.2,8 It must follow the example of C++, supporting new constructs without changing the base syntax to such an extent that it becomes difficult to use the extended language. It should also be as portable as possible.

40、 We therefore implement the extension as a preprocessor which generates code conforming to ANSI/ISO C.12,13 Since we translate the extended language into standard C, static analysis will continue to be done by li</p&g

41、t;<p>　　Array bounds violations</p><p>　　An array bounds violation occurs when an array is indexed by a value which is less than zero or greater than or equal to the number of elements in the array. T

42、he latter error occurs with much greater frequency than the former, so we simplify our discussion below by discussing only the latter case. However, it should be understood that Robust C prevents both errors.</p>

43、<p>　　A more powerful, and more expensive, approach is needed to handle arbitrary arrays which may change size at any time. The more thorough approach is to generate one read and one write module for each data type

44、which appears as the element type of an array. These modules will accept a varying number of arguments (via the method defined in stdarg.h for ANSI/ISO C) to accommodate all arrays of that type regardless of the number o

45、f indices. The arrays themselves will be replaced with structures of th</p><p>　　References to the arrays will then be changed into function calls which pass a pointer to one of these structures, a data valu

46、e (where applicable ), and a list of index values. array is a pointer to the start of the array. nelm is a pointer to the start of a linked list of values representing the upper bounds on the first, second, etc. indices

47、of the array. The precompiler will recognize those situations in which an array’s character can change (e.g. calls to the alloc family of functions or any</p><p>　　Please note that these error checking techn

48、iques are not restricted to programs which are contained in one source file. If an external array is referenced, the preprocessor generates declarations for the external read and write functions and uses them within the

49、current source file. If a pointer argument is used as an array, it is decoded by the appropriate TYPEarr function. Conditional compilation is used to prevent multiple copies of the same function from being seen by the co

50、mpiler. Since arr</p><p>　　Undefined values</p><p>　　Although references to variables which have never been set are a problem for all kinds of variables, they are usually detected by static anal

51、ysis unless arrays are involved. We will detect this error in the array case by adding an additional assertion to the read module described above which ensures that the element being read has been set previously.</p&g

52、t;<p>　　To handle the (expensive) general case, it is necessary to allocate one bit for each element of each array to indicate whether or not the element has been set, clear all these flags at the time of allocati

53、on, set the appropriate bit when the write module is invoked, and verify that the bit is set when the read module is invoked. However, a much less expensive method is available in those cases where at least one ‘bogus’ v

54、alue exists for the elements of an array. A bogus value is any out-ofrange</p><p>　　Ignored library error conditions</p><p>　　Nearly all of the commonly used functions in the standard C librari

55、es have a mechanism for flagging error conditions with special return codes. In Pascal, the analogous functions will generally terminate the program if an error condition arises; in C, it is up to the programmer to test

56、for the error conditions. While this adds much flexibility, it is the case that many C programmers do not bother to check return codes unless an error is expected to occur, such as trying to read past the end of a</p&

57、gt;<p>　　If the programmer had simply said</p><p>　　the preprocessor would have changed it to</p><p>　　THE PROTOTYPE</p><p>　　We have constructed a limited prototype which im

58、plements some of the features discussed above. Many of the examples you have seen in this paper were formatted input and output of the prototype preprocessor. The prototype is a one-pass preprocessor whose only input is

59、 a single source file and whose outputs are the preprocessed source along with a header file. The functionality of the prototype is limited by the fact that it is first in the chain of compilation, prior to the regular C

60、 preprocesso</p><p>　　We found that the task of the preprocessor was complex because there is a wide gap between the services provided by the C language and the services which we want. To make the same exten

61、sions to C++ is much simpler because the gap is not so wide; however, the procedure is still complex enough that we stand to gain much from automating it.</p><p>　　CONCLUSIONS AND FUTURE WORK</p><

62、p>　　We have presented an extended version of the C language which eliminates some of its weaknesses and makes it safer to use. Our syntactic extensions enable the efficient trapping of classes of errors which have not

63、 been handled effectively in the past. We have created a prototype preprocessor to implement some of the extensions. A full implementation, based on non-proprietary preprocessor source and distributed free of charge, cou

64、ld provide many benefits to C programmers world-wide.</p><p>　　Future development of Robust C will enable it to provide more services to programmers and detect more classes of errors. The possibilities for e

65、nhancing C++ will be more fully explored, and several levels of automatic class generation will be provided for more concise object-oriented programming. Many possible improvements will no doubt suggest themselves once

66、the first test implementation is made available.</p><p>　　REFERENCES</p><p>　　R. P. Gabriel, ‘Lisp: good news, bad news, how to win big’, AI Expert, 6, (6), 31-39 (1991).</p><p>　　J

67、. L. Steffen, ‘Adding run-time checking to the Portable C compiler’, Software—Practice and Experience, 22, (4), 305-316 (1992).</p><p>　　B. Stroustrup, ‘The evolution of C++: 1985 to 1989’，Computing Systems,

68、 2, (3), 191-250 (1989).</p><p>　　J. Voas, L. Morrel and K. Miller, ‘Predicting where faults can hide from testing’, IEEE Software, 8, (2), 41-48 (1991).</p><p>　　D. M. Andrews and J. P. Benson,

69、 ‘An automated program testing methodology and its implementation', Tutorial: Software Testing & Validation Techniques, IEEE Computer Society Press, 1981.</p><p>　　D. M. Andrews and J. P. Benson, ‘An

70、 automated program testing methodology and its implementation', Proceedings, 5th International Conference on Software Engineering, 1981.</p><p>　　D. S. Rosenblum, ‘Towards a method of programming with as

71、sertions’, Proceedings, 14th International Conference on Software Engineering, Melbourne, Australia, 1992.</p><p>　　S. C. Kendall, ‘Bcc: runtime checking for C programs’, USENIX Toronto 1983 Summer Conferenc

72、e Proceedings, USENIX Association, El Cerrito, CA, 1983.</p><p>　　S. Kaufer, R. Lopez and S. Pratap, ‘Saber-C: an interpreter-based programming environment for the C language’, USENIX San Francisco 1988 Summ

73、er Conference Proceedings, USENIX Association, El Cerrito, CA, 1988.</p><p>　　S. C. Johnson, ‘A portable compiler: theory and practice', Fifth ACM Symposium on Principles of Programming Languages Confere

74、nce Record, ACM, New York, 1978.</p><p>　　United States Department of Defense, Reference Manual for the Ada Programming Language, U.S. Government Printing Office, Washington, D.C., ANSI/MIL-STD-1815A-1983.&l

75、t;/p><p>　　P. J. Plauger and J. Brodie, Standard C, Microsoft Press, Redmond, Washington, 1989.</p><p>　　American National Standards Institute Technical Committee X3J11 on Programming Language C, D

76、raft Proposed American National Standard Programming Language C, 1988.</p><p>　　C編程語言在增強故障檢測方面的擴展</p><p>　　DAVID W. FLATER AND YELENA YESHA，E. K. PARK</p><p><b>　　概要</b>

77、</p><p>　　學(xué)術(shù)界和業(yè)界部分出于對“軟件危機”的考慮現(xiàn)已經(jīng)開始接受C編程語言。 C編程語言的簡單和可信任的語義掩蓋其了很多常見的錯誤，例如范圍沖突，這些沖突可以被穩(wěn)健的計算機語言諸如Ada等運行的程序代碼檢測并報告出來。這就使C程序在排除故障時變得復(fù)雜，而這是沒必要的。雖然assert宏允許程序員將運行程序一致性檢查添加到他們的程序中，但該宏的例示數(shù)量需要使得C編程語言變得足夠穩(wěn)健以便不是任何程序員都有

78、很大可能性去正確地完成任務(wù)。我們對C語言進行了一些細微的擴展，這些擴展功能支持在運行時進行有效地檢測故障且不降低源代碼的可讀性。 擴展的例子是來自對返回庫存程序、受限的子類型中出現(xiàn)的錯誤代碼的自動檢測，以及對未初始化和/或不存在的數(shù)組元素引用的檢測。</p><p>　　關(guān)鍵詞：C編程語言 可靠性 范圍 錯誤檢測 檢測</p><p><b>

79、　　引言</b></p><p>　　據(jù)說C語言提供了編程語言所需的大約50-80％的編程工具。工具中缺失的一塊是運行錯誤的檢測。 大多數(shù)C編譯器生成的代碼完全無法發(fā)現(xiàn)諸如超出數(shù)組邊界、超出范圍的數(shù)據(jù)值和I / O異常等錯誤，而這些錯誤可由大多數(shù)的Pascal和Ada編譯器生成的代碼來發(fā)現(xiàn)。 有時可以使用獨立的靜態(tài)分析工具（lint）檢測錯誤的指針使用以及對未初始化變量的引用，但靜態(tài)分析無法檢測到所有

80、最常見的程序設(shè)計錯誤。</p><p>　　盡管C編程語言的局限性不僅在于語言的選擇性上經(jīng)常受到外部約束，而且還因為許多人在設(shè)計和編碼上已經(jīng)沉溺于“較差的就是更好的”想法，但C編程語言仍繼續(xù)得到使用。通常情況下，為了縮短軟件的生產(chǎn)時間而在軟件的可靠性和正確性上有所忽視。我們的任務(wù)是在不改變?nèi)藗儗幊陶Z言的使用習慣下，去提高C編程語言的可靠性和正確性。</p><p>　　有人可能會表示C

81、++ 3在某一方面有所提升。 Gabriel指出C ++比C更接近我們的需要，這一說法變成了現(xiàn)實。然而，雖然可以使用C ++類實現(xiàn)內(nèi)部一致性檢查，但仍然需要大多數(shù)程序員為了保證質(zhì)量而去付出更多努力。 出于這個原因，我們對C編程語言做的擴展也將有效地應(yīng)用于C ++。</p><p><b>　　研究動機</b></p><p>　　C語言的松散性導(dǎo)致出現(xiàn)了很多類型的編碼

82、錯誤，這些編碼錯誤在它們的出現(xiàn)頻率和檢測困難方面確實是隱藏得很深。 其中一類的錯誤是數(shù)組界沖突。 盡管許多人認為出界指針是C程序中的主要問題，但依據(jù)我們的經(jīng)驗數(shù)組界沖突更頻繁。特別是在學(xué)術(shù)環(huán)境中，經(jīng)常發(fā)生這種情況的原因可能如下：</p><p>　　1 大多數(shù)在大學(xué)學(xué)習的程序員都使用Pascal 作為他們的第一編程語言。那些知道如何編程的人在接受培訓(xùn)時仍然會接觸到Pascal編程。</p><

83、p>　　2盡管Pascal在數(shù)組索引方面有很大的靈活性，但慣例是從1開始索引。此外，Pascal在運行程序時可捕獲數(shù)組界沖突。</p><p>　　3程序員學(xué)習的是一種常見的編碼方式，從而實現(xiàn)從1到N的數(shù)組索引。編程人員還知道編碼時可以不必非常謹慎，因為編程中的錯誤通常會導(dǎo)致軟件異常并終止運行并會顯示錯誤信息的來源，這一點很有意義。</p><p>　　4當程序員被迫切換到C語言時，

84、他們很有傾向于從1開始而不是從0開始掃描數(shù)組索引。</p><p>　　5除非編譯器或鏈接器恰好將數(shù)組放置在內(nèi)存段的末端，否則對不存在的元素N的引用會產(chǎn)生分段沖突或類似的硬件異常，導(dǎo)致編碼錯誤極有可能從未被發(fā)現(xiàn)。</p><p>　　數(shù)組界沖突的影響只有放在機器代碼的那一個級別才有意義。 被覆蓋的數(shù)據(jù)的標識不能確定其來源，因為它們在程序執(zhí)行時取決于內(nèi)存中數(shù)據(jù)的排列方式。 如果數(shù)據(jù)是動態(tài)分配

85、的，每次程序運行時可以有不同的排列; 否則，每次程序重新編譯時，排序都會改變。</p><p>　　當數(shù)組不在內(nèi)存段末尾時發(fā)現(xiàn)故障的可能性很小。 有幾個子分類：</p><p>　　（a）當數(shù)據(jù)遭到破壞后（無意間被覆蓋），數(shù)據(jù)永遠就不會再被引用。在這種情況下，故障完全被掩蓋了。</p><p>　?。╞）破壞的數(shù)據(jù)的敏感度較低。有時候靈敏一詞用于表達軟件中導(dǎo)致特定故

86、障的可能性。在我們引用的文獻里使用代碼段分析來估計這種可能性。對于我們正在考慮的故障類型，有時故障被掩蓋的可能性與特定數(shù)據(jù)的總體使用情況直接相關(guān)，而不是與任何特定代碼段相關(guān)。因此，我們認為在執(zhí)行程序中引用數(shù)據(jù)的靈敏性是有效的。我們的經(jīng)驗是程序引用的絕大多數(shù)數(shù)據(jù)的敏感性隨著程序大小的增加而迅速降低;不幸的是數(shù)組界沖突導(dǎo)致的故障通常是間歇性的并且難以復(fù)制。</p><p>　?。╟）破壞的數(shù)據(jù)具有高度的敏感性。當程序

87、員恰好破壞了一些對繼續(xù)執(zhí)行程序至關(guān)重要的數(shù)據(jù)時，就會出現(xiàn)特殊情況。故障可能是間歇性的，但它們很可能是系統(tǒng)性的。即便如此，故障的發(fā)生不能被定位好也是經(jīng)常發(fā)生的。可以考慮以下常見的情況。發(fā)生程序崩潰。程序員進入到一個源代碼級的調(diào)試程序中并逐步執(zhí)行程序，直到他或她發(fā)現(xiàn)錯誤。程序員糾正錯誤、重復(fù)測試用例、程序正常結(jié)束。其結(jié)論是問題解決了?，F(xiàn)在考慮以下關(guān)于實際發(fā)生的情況。該錯誤是數(shù)組界沖突。發(fā)生故障是因為數(shù)組尾部后面的數(shù)據(jù)被破壞，這對執(zhí)行程序非常

88、重要。程序員找到并修復(fù)了一個不相關(guān)的問題，結(jié)果是要重新編譯數(shù)據(jù)，這與內(nèi)存中的排列略有不同。現(xiàn)在原始故障仍然存在，但由于被破壞的數(shù)據(jù)具有較低的靈敏度，因此它被掩蓋了。</p><p>　　很顯然數(shù)組界沖突帶來的唯一影響是很可能會導(dǎo)致程序在發(fā)生沖突的地方異常終止，這是硬件異常的情況。它必須滿足許多與編譯器和硬件相關(guān)的條件，才會發(fā)生這種錯誤模式。如果正在開發(fā)軟件的硬件平臺不支持受保護的內(nèi)存分割，那么我們會遇到更大的問題

89、。我們不僅失去了有關(guān)于數(shù)組界沖突的最佳指標，而且還會遭遇另一種錯誤類型。在另一個硬件平臺上可能出現(xiàn)硬件異常的情況下，我們可能會發(fā)生代碼損壞。</p><p><b>　　研究背景和相關(guān)工作</b></p><p>　　為了在脆弱的語言環(huán)境中編寫穩(wěn)健的程序，需要添加代碼來明確執(zhí)行時所需的運行時間檢測。這些檢測是可執(zhí)行斷言的一種形式。由于程序員手動添加斷言來測試最常見的問

90、題非常耗時且容易出錯，因此最好有一個工具來自動添加斷言。插入代碼以在運行時測試斷言是一項傳統(tǒng)的技術(shù)，它已被證明對開發(fā)可靠的軟件非常有幫助[5,6]。我們嘗試另外去擴展C語言，以App7為基礎(chǔ)提供更強的語義，App7應(yīng)用程序使用了與我們很相似的替換預(yù)處理程序，將注釋（C語言中出現(xiàn)的有效語言擴展）轉(zhuǎn)換為基本語言的結(jié)構(gòu)。我們的工作和應(yīng)用程序開發(fā)之間的主要區(qū)別在于語言擴展的本身以及研究其設(shè)計過程中要陷入的錯誤種類。應(yīng)用程序首先要設(shè)計的是用于檢測

91、應(yīng)用程序功能的登錄和退出的條件;穩(wěn)健的C編程語言更偏離了基本語言，但它提供了對超出范圍的數(shù)據(jù)進行的全面檢測，在沒有自動化工具的情況下，在基本語言中執(zhí)行起來要困難得多。</p><p>　　在本文中，采用一種不同的方法來提升C編程語言的穩(wěn)健型，那就是在不改變語言句法的情況下去增強語言的語義。Bcc2,8似乎是采取這種方法的第一個實用程序。 Bcc在C語言代碼中捕捉各種可能的錯誤，包括越界指針、懸空指針、通過常量間接

92、尋址、濫用空指針、指針算術(shù)溢出和數(shù)組下標沖突。不幸的是，由此產(chǎn)生的程序速度慢得難以忍受。Sabre-C2,9使用C語言注釋器來捕捉錯誤，而不是使用翻譯器或增強型編譯器，但它的速度更慢。最后，在bcc框架內(nèi)，rtcc由Portable C Compiler構(gòu)建而成，可以在減速因子約為10的情況下，檢測數(shù)組下標和指針界限。</p><p>　　通過對C編程語言句法的擴展，我們可以捕捉不符合語法擴展的錯誤種類。例如，自

93、動捕獲由庫函數(shù)標記的不切實際的錯誤條件，除非程序員有指定何時明確或忽略這些錯誤。對于程序員在受約束子類型中（其可能值的集合的數(shù)據(jù)類型受約束11）指定合規(guī)值也沒有進行實際替代。擴展語法使我們能夠使用更高效的錯誤捕獲機制。在一般情況下，對尚未初始化的數(shù)組元素的引用檢測，需要維護每個數(shù)組元素的標識以指示其狀態(tài)。當元素類型不是受約束的子類型時，編譯器無法初始化數(shù)組元素以指示它們沒有被初始化。但是，如果我們給程序員一組未初始化的數(shù)組元素，并提供指

94、示值的方法，我們可以避免維護其標識的成本。這還帶來了額外的好處，即程序員將能夠明確地不再使用失效的數(shù)組元素，且不會產(chǎn)生范圍沖突。</p><p><b>　　穩(wěn)健C編程語言</b></p><p>　　為了使穩(wěn)健C編程語言為大家所接受，它不得強加于程序員。它必須遵循C ++的例子，支持新的構(gòu)造，而不會將基本語法改為難以使用的擴展語言。 它應(yīng)該盡可能的便攜。 因此，我們

95、將該擴展實現(xiàn)為預(yù)處理程序，該預(yù)處理程序生成符合ANSI / ISO C.12要求的代碼。由于我們將擴展語言翻譯為標準C的語言，靜態(tài)分析將繼續(xù)由lint完成; 唯一的區(qū)別是lint會在每個翻譯過的源文件中自動運行。 在下面的小節(jié)中，我們將討論穩(wěn)健C編程語言中要避免的一些問題及其解決方案。</p><p><b>　　數(shù)組界沖突</b></p><p>　　當數(shù)組的索引值

96、小于零或大于或等于數(shù)組中元素的數(shù)量時，就會發(fā)生數(shù)組界沖突。 后一種錯誤的發(fā)生頻率比前者大得多，所以我們通過僅討論后一種情況來簡化我們的討論。 但是，應(yīng)該明白，穩(wěn)健C語言可以防止這兩種錯誤的發(fā)生。</p><p>　　在此我們需要更強大的方法來處理隨時可能改變其值大小的任意數(shù)組。 一個更為徹底的方法是為每個數(shù)據(jù)類型生成一個讀取和一個寫入模塊，這些數(shù)據(jù)類型顯示為數(shù)組的元素類型。 這些模塊將接受許多不同數(shù)目的參數(shù)（通過

97、stdarg.h中為ANSI / ISO C定義的方法），以適應(yīng)該類型的所有數(shù)組，而不用考慮索引數(shù)目。 數(shù)組本身將被替換為以下形式的結(jié)構(gòu)：</p><p>　　之后，對數(shù)組的引用將被更改為函數(shù)調(diào)用，它們將指針傳遞給這些結(jié)構(gòu)中的一個，可以是數(shù)據(jù)值（如果適用）也可以一列索引值。 數(shù)組是指向數(shù)組開端的指針。 nelm是指向表示數(shù)組的第一、第二等索引的上限鏈接列表的指針。 預(yù)編譯程序?qū)⒆R別數(shù)組中可以改變的字符（例如調(diào)用a

98、lloc函數(shù)族或?qū)?shù)組指針的任何其他指定），并生成函數(shù)以通過上述數(shù)組結(jié)構(gòu)執(zhí)行所需的操作，修改數(shù)組指針和根據(jù)需要修改長度字段。</p><p>　　圖一 固定大小的數(shù)組（處理之前）</p><p>　　圖二 固定大小的數(shù)組（處理之后）</p><p>　　需要指出的是這些錯誤檢查技術(shù)不限于僅僅包含在一個源文件中的程序。 如果引用外部數(shù)組，則預(yù)處理程序會為

99、外部數(shù)據(jù)進行讀取并寫入函數(shù)，并在當前源文件中使用它們。 如果一個指針參數(shù)被用作一個數(shù)組，它將被合適的TYPEARr函數(shù)解碼。 條件編譯用于防止編譯器遇到同一個函數(shù)的多個副本。 由于更高效的固定大小格式的數(shù)組在傳遞給</p><p>　　非特定大小任意數(shù)組的指針函數(shù)時必須轉(zhuǎn)換為TYPEARr格式，因此盡可能提供完整的聲明非常重要。</p><p><b>　　未定義的值</b