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

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編程語言在增強(qiáng)故障檢測(cè)方面的擴(kuò)展</p><p>　　DAVID W. FLATER AND YELENA YESHA，E. K. PARK</p><p><b>　　概要</b>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

97、stdarg.h中為ANSI / ISO C定義的方法），以適應(yīng)該類型的所有數(shù)組，而不用考慮索引數(shù)目。 數(shù)組本身將被替換為以下形式的結(jié)構(gòu)：</p><p>　　之后，對(duì)數(shù)組的引用將被更改為函數(shù)調(diào)用，它們將指針傳遞給這些結(jié)構(gòu)中的一個(gè)，可以是數(shù)據(jù)值（如果適用）也可以一列索引值。 數(shù)組是指向數(shù)組開端的指針。 nelm是指向表示數(shù)組的第一、第二等索引的上限鏈接列表的指針。 預(yù)編譯程序?qū)⒆R(shí)別數(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>　　需要指出的是這些錯(cuò)誤檢查技術(shù)不限于僅僅包含在一個(gè)源文件中的程序。 如果引用外部數(shù)組，則預(yù)處理程序會(huì)為

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