Unspecified behavior

Abstract: The C preprocessor is used in many C projects to support variability and portability. However, researchers and practitioners criticize the C preprocessor because of its negative effect on code understanding and maintainability and its error proneness. More importantly, the use of the preprocessor hinders the development of tool support that is standard in other languages, such as automated refactoring. Developers aggravate these problems when using the preprocessor in undisciplined ways (e.g., conditional blocks that do not align with the syntactic structure of the code). In this article, we proposed a catalogue of refactorings and we evaluated the number of application possibilities of the refactorings in practice, the opinion of developers about the usefulness of the refactorings, and whether the refactorings preserve behavior. Overall, we found 5,670 application possibilities for the refactorings in 63 real-world C projects. In addition, we performed an online survey among 246 developers, and we submitted 28 patches to convert undisciplined directives into disciplined ones. According to our results, 63 percent of developers prefer to use the refactored (i.e., disciplined) version of the code instead of the original code with undisciplined preprocessor usage. To verify that the refactorings are indeed behavior preserving, we applied them to more than 36 thousand programs generated automatically using a model of a subset of the C language, running the same test cases in the original and refactored programs. Furthermore, we applied the refactorings to three real-world projects: BusyBox , OpenSSL , and SQLite . This way, we detected and fixed a few behavioral changes, 62 percent caused by unspecified behavior in the C programming language.

Abstract: In this paper, we introduce a graphic specification technique, called state transition diagrams (STD), and show the application to the feature interaction problem. Using a stream-based formal semantics, we provide refinement rules for STDs. Refinements define an implementation relation on STD specifications. We view features as particular refinements which add previously unspecified behavior to a given STD specification. The refinement relation is then used to add features, and to define the notion of conflicting features. Our techniques are demonstrated by a systematic development of an example given in [25].

Abstract: In a typical Model-Based Design (MBD) process for Cyber-Physical Systems, an initial `simple' Model is successively refined and made more accurate and complex; then it is implemented on a real-time computational platform, and further modified to yield an Implementation. The goal is to produce a system that satisfies a formal specification Φ. This successive refinement raises the question of how “close” are the “simple” Model and the“complex”Implementation. Answering this question is important because it is not always possible to verify formally that the Implementation satisfies the specification Φ. Moreover, even if the Implementation satisfies Φ, it will have unspecified behavior which might exhibit bugs. By quantifying the `closeness' between Model and Implementation, our level of confidence in the Implementation derives from our confidence in the Model, and the fact that the Model satisfies Φ.

Abstract: Requirements models for large systems typically cannot be developed in a single step, but evolve in a sequence of iterations. We have developed such an iterative modeling process which is based on the interactive simulation of yet incomplete and semi-formal models. Missing parts are completed interactively by the user simulating the model. We start by modeling type scenarios (i.e. use cases) and simulate these interactively before having specified any system behavior. Such simulation runs yield exemplary system behavior in form of message sequence charts (MSCs). The modeler can then generalize this recorded partial behavior into statecharts. The resulting model is simulated again, (i) for validating that the modeled behavior matches the previously recorded behavior, and (ii) for recording new yet unspecified behavior in a next iteration step. Thus, recording MSCs by playing-through the scenarios and transforming MSCs to statecharts stimulate and drive each other.In this paper we focus on two elements of our approach: firstly, we describe the syntax and semantics of our scenario language. Secondly, we give an example how our modeling process works.