T. Austin, S. Breach, and G. Sohi. E#cient detection of all pointer and array access errors. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI '94), SIGPLAN Notices 29(6), pages 290-- 201, Orlando, FL, June 1994.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....objects (e.g. function return addresses in the stack) but it can still reads and modifies any data in the memory by forging pointer o#sets. Jones and Kelly claims their method detects pointer o#set forging, but it does not seem to work when on memory pointers are overwritten by integers. Safe C [1] can detect all error caused by early deallocation of memory regions. However, their paper does not mention about cast operations and, as far as we know, supporting unlimited cast operations with Safe C seems non trivial, for the same reason as that of Jones and Kelly s work. Patil and Fischer ....

Todd M. Austin, Scott E. Breach, and Gurindar S. Sohi. E#cient detection of all pointer and array access errors. In Proc. '94 Conference on Programming Language Design and Implementation (PLDI), pages 290--301, 1994.

....Simple . The assert( facility is found in many programming languages. It allows programmers to abort execution immediately if the boolean argument is not true. Robust code uses assertions extensively as a form of documentation and reassurance. Automated instrumentation tools such as SafeC [2], CCured [19] and others also introduce assertions that help enforce safety properties that the user forgets to check. We use Phase I of the translation (Figure 2) to turn Simple into Simpler (i.e. Simple with renamed variables and desugared while loops) The only change necessary to ....

T.M. Austin, S.E. Breach, and G.S. Sohi. E#cient detection of all pointer and array access errors. In Proceedings of the SIGPLAN '94 Conference on Programming Language Design and Implementation, pages 290--301, Orlando, Florida, June 1994.

....allocation, and dynamic region allocation. We feel that Cyclone is a unique and promising point in the programming language design space, but many other systems share some features with Cyclone. Making C Safe. Many systems, including but certainly not limited to LCLint [10, 9] SLAM [3] Safe C [2], and CCured [25] aim to make C code safe. Some of these systems, such as LCLint, are meant to be static bug finding tools. Like Cyclone, they usually require restricted coding idioms or additional annotations, but unlike Cyclone, they o#er no soundness guarantees. In this way, these static tools ....

T. M. Austin, S. E. Breach, and G. S. Sohi. E#cient detection of all pointer and array access errors. In ACM Conference on Programming Language Design and Implementation, pages 290--301, Orlando, FL, June 1994.

....heap allocation, and dynamic region allocation. We feel that Cyclone is a unique and promising point in the programming language design space, but many other systems share some of these features. Making C Safe Many systems, including (but not limited to) LCLint [9, 8] SLAM [3] SafeC [2], and CCured [19] aim to make C code safe. Some of these systems, such as LCLint, are meant to be static bug finding tools. Like Cyclone, they usually require restricted coding idioms or additional annotations, but unlike Cyclone, they o#er no soundness guarantees. In this way, these static tools ....

T. M. Austin, S. E. Breach, and G. S. Sohi. E#cient detection of all pointer and array access errors. In ACM Conference on Programming Language Design and Implementation, pages 290-- 301, June 1994.

....more liberal than Java in what they allow programmers to express; the static type system is weaker; and the run time system provides little in the way of protection from errors caused by misuse of casts, bad pointer dereferences, or array out of bounds errors. Programmers can use Purify[1] Safe C[2], and shadow processing[3] to help detect bad memory accesses, but those tools provide no help with the many additional kinds of errors that can be introduced into C and C programs due to their weak type systems. This paper describes the design and implementation of a tool for C programs that ....

....of work is similar to ours in its approach to type checking, the di#erences in the languages handled by the two approaches is significant. Approaches to detection of errors in C programs by means of executing a program instrumented to perform run time checks have been developed in the past. Safe C[2] provides run time detection of array access and pointer dereference errors, such as array out of bounds errors, stale pointer accesses, and accesses resulting from erroneous pointer arithmetic. This is done by keeping track of attributes of the referent of each pointer by transforming C code to ....

T. Austin, S. Breach, and G. Sohi. E#cient detection of all pointer and array access errors. In ACM SIGPLAN '94 Conference on Programming Language Design and Implementation, 1994.

....of ensuring type consistency in the hands of the programmer. While the programmer is given the flexibility to ignore types, our hypothesis is that a violation of type consistency is a likely indicator of a programming bug. Other run time debugging tools, like Purify[4] and Safe Pointers[2], have been proposed, developed, and found to be useful. Our tool, however, can catch subtler bugs that cannot be detected by these tools. Generally, when data of one type is used as a di#erent type, our tool will report an error. If this bug does not violate the spatial constraints of the C ....

T. Austin, S. Breach, G. Sohi. E#cient Detection of All Pointer and Array Access Errors. SIGPLAN '94 Conference on Programming Language Design and Implementation, 1994. 7

....# B # C is replaced by the set of normal edges A 1 # B, A 2 # B, A j # B . Figure 5 gives some statistics for the benchmark programs we analyzed; bc, bison, flex, gzip and ispell are Gnu Unix utilities; agrep is described in [WM92] anagram has been used in the experiments of [ABS94], while allroots, football and simulator were used in the experiments of [LRZ93] Figure 6 gives the distribution of chains by length in each program. The taller bar gives the percentage of chains that have length # 10, while the solidly shaded portion indicates the percentage of chains that ....

T. Austin, S. Breach, and G. Sohi. E#cient detection of all pointer and array access errors. In ACM SIGPLAN '94 Conference on Programming Language Design and Implementation, pages 290--301, June 1994.

....more liberal than Java in what they allow programmers to express; the static type system is weaker; and the run time system provides little in the way of protection from errors caused by misuse of casts, bad pointer dereferences, or array out of bounds errors. Programmers can use Purify[9] Safe C[2], and shadow processing[14] to help detect bad memory accesses, but those tools provide no help with the many additional kinds of errors that can be introduced into C and C programs due to their weak type systems. This paper describes the design and implementation of a tool for C programs that ....

....behavior of the original program and that of the instrumented one di#er, even though the cause of the errors is the same. 5 Related Work Approaches to detection of errors in C programs by means of executing a program instrumented to perform run time checks have been developed in the past. Safe C[2] provides run time detection of array access and pointer dereference errors, such as array outof bounds errors, stale pointer accesses, and accesses resulting from erroneous pointer arithmetic. This is done by keeping track of attributes of the referent of each pointer by transforming C code to ....

T. Austin, S. Breach, and G. Sohi. E#cient detection of all pointer and array access errors. In ACM SIGPLAN '94 Conference on Programming Language Design and Implementation, 1994.

No context found.

T. Austin, S. Breach, and G. Sohi. E#cient detection of all pointer and array access errors. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI '94), SIGPLAN Notices 29(6), pages 290-- 201, Orlando, FL, June 1994.

No context found.

T. M. Austin, S. E. Breach, and G. S. Sohi. E#cient detection of all pointer and array access errors. In Proc. SIGPLAN Conf. Programming Language Design and Implementation, pages 290--301, June 1994.

No context found.

T. M. Austin, S. E. Breach, and G. S. Sohi. E#cient detection of all pointer and array access errors. In ACM SIGPLAN Conference on Programming Language Design and Implementation, pages 290--301, Orlando, Florida, 20--24 June 1994.

No context found.

T. M. Austin, S. E. Breach, and G. S. Sohi. E#cient detection of all pointer and array access errors. In Proceedings of the ACM SIGPLAN'94 Conference on Programming Language Design and Implementation (PLDI), pages 290--301, Orlando, Florida, june 1994.

No context found.

Austin TM, Breach SE, Sohi GS. E#cient Detection of All Pointer and Array Access Errors. ACM SIGPLAN 94 Conference on Programming Language Design and Implementation ACM: Orlando, FL, June 1994; 290--301.

No context found.

Todd M. Austin, Scott E. Breach, and Gurindar S. Sohi. E#cient Detection of All Pointer and Array Access Errors. In Proceedings of the ACM SIGPLAN '94 Conference on Programming Language Design and Implementation, pages 290--301, Orlando, Florida, U.S.A., June 1994. ACM. (Cited on pages 41 and 61.)

No context found.

Todd M. Austin, Scott E. Breach, and Gurindar S. Sohi. E#cient detection of all pointer and array access errors. In ACM Conference on Programming Language Design and Implementation, pages 290--301, June 1994.

No context found.

Todd Austin, Scott Breach, and Gurindar Sohi. E#cient detection of all pointer and array access errors. In ACM Conference on Programming Language Design and Implementation, pages 290--301, Orlando, FL, June 1994.

No context found.

Todd M. Austin, Scott E. Breach, and Gurindar S. Sohi. E#cient detection of all pointer and array access errors. SIGPLAN Notices, 29(6):290--301, June 1994. Proceedings of the ACM SIGPLAN '94 Conference on Programming Language Design and Implementation.

No context found.

T. M. Austin, S. E. Breach, and G. S. Sohi. E#cient detection of all pointer and array access errors. SIGPLAN Notices, 29(6):290--301, June 1994. Proceedings of the ACM SIGPLAN '94 Conference on Programming Language Design and Implementation.

No context found.

T. M. Austin, S. E. Breach, and G. S. Sohi. E#cient detection of all pointer and array access errors. SIGPLAN Notices, 29(6):290--301, June 1994. Proceedings of the ACM SIGPLAN '94 Conference on Programming Language Design and Implementation.

No context found.

T. M. Austin, S. E. Breach, and G. S. Sohi. E#cient detection of all pointer and array access errors. SIGPLAN Notices, 29(6):290--301, June 1994. Proceedings of the ACM SIGPLAN '94 Conference on Programming Language Design and Implementation.

No context found.

T. Austin, S. Breach, and G. Sohi. E#cient detection of all pointer and array access errors. In ACM SIGPLAN Conf. on Programming Language Design and Implementation, pp. 290--201, Orlando, FL, June 1994.

No context found.

T. Austin, S. Breach, and G. Sohi. E#cient detection of all pointer and array access errors. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI '94), SIGPLAN Notices 29(6), pages 290-- 201, Orlando, FL, June 1994.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC