• / 18
  • 下载费用:29.9 金币  

【精品文档】02中英文双语计算机专业C#语言外文文献翻译成品:C编程语言在增强故障检测方面的扩展

关 键 词:
外文文献翻译成品 【精品文档】 中英文双语外文文献翻译成品 中英文双语计算机专业外文翻译成品 专业外文文献翻译成品 中英文双语外文文献翻译成品 中英文双语外文文 计算机专业C语言
资源描述:
此文档是毕业设计外文翻译成品( 含英文原文+中文翻译),无需调整复杂的格式!下载之后直接可用,方便快捷!本文价格不贵,也就几十块钱!一辈子也就一次的事!外文标题:Extensions to the C Programming Language for Enhanced Fault Detection外文作者:DW Plater , Y Yesha , EK Park文献出处:《Software Practice & Experience》 , 2018 , 23 (6) :617-628(如觉得年份太老,可改为近2年,毕竟很多毕业生都这样做)英文3379单词, 17889字符(字符就是印刷符),中文5478汉字。Extensions to the C Programming Language for Enhanced Fault DetectionDAVID W. FLATER AND YELENA YESHA,E. K. PARKSummaryThe 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 would 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 checks to their programs, the number of instantiations of this macro needed to make a C program robust makes it highly unlikely that any programmer could correctly perform the task. We make some unobtrusive extensions to the C language which support the efficient detection of faults at run-time without reducing the readability of the source code. Examples of the extensions are automatic checking of error codes returned by library routines, constrained subtypes and detection of references to uninitialized and/or non-existent array elements.key words :CReliabilityRangecheckingErrorcheckingIntroductionIt has been written that 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, 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 uninitialized variables can sometimes be detected with separate tools for static analysis (lint), but static analysis cannot detect all of the most common programmer errors.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 people 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 way that reliability and correctness will be easier to achieve without removing the language’s addictive qualities.One might claim that C++3 is just such an enhancement. Gabriel points out that C++ 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 exert for the sake of quality assurance. For this reason, the extensions which we make to C will apply productively to C++ as well.MOTIVATIONThe looseness of the C language has 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 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 follows:1. Most programmers wholearn to program in a collegeor universityusePascalas their first programming language. Those who know how to program already are nevertheless trained in the Pascal programming style.2. Although Pascal allows significant flexibility in the indexing of arrays, the convention is to start indexing from 1. Furthermore, Pascal traps array bounds violations at run-time.3. 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 coding them since errors in these loops usually result in abnormal termination with a helpful error message showing the source of the problem.4. When this programmer is forced to switch to the C language, he or she has a strong tendency to scan array indices beginning with 1 instead of 0.5. Unless the compiler or linker happens to place the array at the very end of a memory segment, so that a reference 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.The effects of an array 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 program 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.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:(a) The data which are clobbered (unintentionally overwritten) are never referenced after the clobbering occurs. In this case, the fault is completely masked.(b) The clobbered data have low sensitivity. The word sensitivity is sometimesused to 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 considering, 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 sensitivity of a datum in an executing program. It is our experience that the sensitivity of the vast majority of data referenced by a program quickly decreases as the size of the program increases; the unfortunate consequence is that failures resulting from array bounds violations are usually intermittent and difficult to replicate. (c)The clobbered data have high sensitivity. This is the exceptional case in which the programmer is lucky enough to have clobbered some data which 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 scenario. A program crash occurs. The programmer enters a source-level debugger and steps through the program until he or she notices an error. The programmer corrects a fault, repeats the test case, and the program terminates normally. Conclusion: problem solved. Now consider the following description of what has actually occurred. The fault is an array bounds violation. The failure occurred because the datum following the end of the array was clobbered and was important to the execution of the program. The programmer located and repaired an unrelated problem, with the result that the arrangement of data in memory was slightly different after recompilation. Now the original fault is still present, but it is masked because the datum being clobbered has lower sensitivity.Clearly the only case in which an array bounds violation is 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. If 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 have also gained an entire new class of failures. In those cases where a hardware exception might have been raised on another hardware platform, we instead have the possibility of code corruption.BACKGROUND AND RELATED WORKIn 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. These 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 add them automatically. Whereas inserting code to test assertions at run-time is an old technique which has been proven to be very helpful in the development of reliable software,5,6 the only other attempt we know of to extend the C language itself to provide a stronger semantic base for such assertions is App7 App uses a replacement preprocessor much like ours to convert annotations, which are effectively language extensions appearing within C comments, into constructs in the base language. The primary differences between our work and App lie in the language extensions themselves and the kinds of errors they are designed to trap. App is first and foremost designed to check entry and exit conditions on functions; Robust C is more of a departure from the base language, but it provides global checking for out of range data, which is much more difficult to implement in the base language without automated tools.A different approach which has been taken to improving C’s robustness 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-bounds 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 slow.2 Saber-C2,9 traps errors using a C interpreter instead of a translator or an enhanced compiler, but it suffers from even greater slowdown.2 Finally, rtcc, built out of the Portable C Compiler2,10 in the spirit of bcc, checks array subscripts and pointer bounds with a slowdown factor of approximately ten.2By 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 error 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 programmer to specify the legal values for a constrained subtype (a data type whose set of possible values is constrained11) immediately within its declaration. Extending the syntax enables us to use more efficient error trapping mechanisms as well. In the general case, detecting references to elements of arrays which have not been initialized requires the maintenance of a flag for every array element to indicate its status. When the element type is not a constrained subtype, there is no value to which the compiler can initialize array elements to indicate that they have not otherwise been initialized. However, if we give the programmer a way to provide an indicator value for uninitialized array elements, we can avoid the expense of maintaining flags. This has the added benefit that the programmer will be able to explicitly invalidate array elements which are no longer being used without generating a range violation.ROBUST CIn order to gain acceptance, Robust C must not impose upon the programmer.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. 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 lint; the only difference will be that lint will be run automatically on every translated source file. In the following subsections we will discuss some of the problems which Robust C is meant to obviate and their solutions.Array bounds violationsAn 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. The 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.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 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 of indices. The arrays themselves will be replaced with structures of the following form:References to the arrays will then be changed into function calls which pass a pointer to one of these structures, a data value (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 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 other assignments to the array pointer) and generate functions to perform the desired operations through the above array structure, modifying the array pointer and length fields as necessary.Please note that these error checking techniques 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 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 compiler. Since arrays in the more efficient fixed-size format must be converted to the TYPEarr format when they are passed to functions expecting a pointer to an array of no particular size, it is important to provide complete declarations whenever possible.Undefined valuesAlthough references to variables which have never been set are a problem for all kinds of variables, they are usually detected by static analysis unless arrays are involved. We will detect this error in the array case
展开阅读全文
  麦档网所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
0条评论

还可以输入200字符

暂无评论,赶快抢占沙发吧。

关于本文
本文标题:【精品文档】02中英文双语计算机专业C#语言外文文献翻译成品:C编程语言在增强故障检测方面的扩展
链接地址:https://www.maidoc.com/p-15592948.html
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

[email protected] 2018-2020 maidoc.com版权所有  文库上传用户QQ群:3303921 

麦档网为“文档C2C模式”,即用户上传的文档所得金币直接给(下载)用户,本站只是中间服务平台,本站所有文档下载所得的金币归上传人(含作者)所有。
备案号:蜀ICP备17040478号-3  
川公网安备:51019002001290号 

本站提供办公文档学习资料考试资料文档下载


收起
展开