Conditional compilation is one of the most powerful parts of a C/C++ environment available for building software for different platforms with different feature sets. Although conditional compilation is powerful, it can be difficult to understand and is error-prone. In large software systems, file inclusion, conditional compilation and macro substitution are closely related and are often largely interleaved. Without adequate tools, understanding complex header files is a tedious task. This practice may even be complicated as the hierarchies of header files grow with projects. This paper presents our experiences of studying conditional compilation based on the symbolic execution of preprocessing directives. Our two concrete goals are: for any given preprocessor directive or C/C++ source code line, finding the simplest sufficient condition to reach/compile it, and finding the full condition to reach/compile that code line. Two different strategies were used to achieve these two goals. A series of experiments conducted on the Linux kernel are presented.

The aim of the experiment presented in this paper is to present an insight into the evaluation of the potential benefits of introducing a function clone detection technology in an industrial software development process. To take advantage of function clone detection, two modifications to the software development process are presented. Our experiment consists of evaluating the impact that these proposed changes would have had on a specific software system if they had been applied over a 3 year period (involving 10000 person-months), where 6 subsequent versions of the software under study were released. The software under study is a large telecommunication system. In total 89 million lines of code have been analyzed. A first result showed that, against our expectations, a significant number of clones are being removed from the system over time. However, this effort is insufficient to prevent the growth of the overall number of clones in the system. In this context the first process change would have added value. We have also found that the second process change would have provided programmers with a significant number of opportunities for correcting problems before customers experienced them. This result shows a potential for improving the software system quality and customer satisfaction

Provides a heuristic framework for the analysis and design of source policing mechanisms for ATM networks. The authors first introduce a function called the time /spl epsiv/-quantile function associated with a source and a second function associated with the policing mechanism. These two characteristics when used in conjunction allow to obtain a useful design tool for source policing. The authors illustrate the use of this framework on source models as well as on real video sources. This framework leads also to a new and natural notion of the response time (called detection time) of the policing mechanism and show how the heuristic framework allows for a quick estimation of this detection time.>

The authors highlight the fact that most of the policing schemes proposed in the literature neglect important information on the past cell blocking behavior of the policing mechanism. They propose a modification of these schemes in which the discarded cell information is used, with almost no overhead compared to the usual strategies. The behavior of the modified policing mechanisms is discussed. This new behavior is illustrated by using the generalized leaky bucket to police the mean rate of a source. Analysis using an on/off input process shows that the modified versions detect smaller-magnitude abuses, police the sources closer to their declared resources utilization, and have a faster response time. Results are presented showing that the generalized sliding window exhibits the same kind of behavior.>

A tool for interactively finding hard-to-test nodes and assessing the impact of test points on random pattern testability is described. With this tool, a set of test points which bring the fault coverage to almost 100% was found for the hardest ISCAS benchmark. It is shown that observation test points only are not sufficient, and thus controllable test points are required. The added test points yield test sets shorter than those necessary with weighted random test sets. On the basis of these findings, a pragmatic approach to built-in self-test (BIST) is proposed. New CMOS BILBO-like test latches that are self-tested are also proposed. A modified implementation for the force-observe (F-O) test points is proposed, and an evaluation of the relative overhead associated with both the circular scan path and the added test points is presented.>