ELSEVIER Information and Software Technology 38 (1996) 45 l-453

INKHMATION AND

SoFTwARE lEni-

Sharing objects as structural defects in object-oriented programming without safe typing

David Rine*

Computer Science Department, George Mason University, Fairfax, VA 22030-4444, USA

Received 15 May 1995; revised 25 September 1995; accepted 26 October 1995

Abstract

Many object-based and object-oriented programming languages have no way of directly preventing structural defects due to the sharing of objects. Languages such as C++, Smalltalk and Eiffel fall into the category of unsafe object languages where these defects can and do occur. This error can be prevented by use of object languages supporting safe, strong typing structures. Examples falling into this category are Ada83 and Ada95 with their limited private, strong typing and unsharable constructs. The paper shows how unsafe object sharing is prevented using these constructs. Applications where safety and security are important should be implemented using languages in this latter category.

Keywords: Object-oriented programming; Object sharing; Structural defects; Security

1. The sharing objects structural defects

The purpose of this paper is to report on structural defects in object-oriented programming due to object sharing, where the supporting object-oriented program- ming language lacks safe typing. C++ is presently the most popular statically typed object-oriented program- ming language, and Smalltalk is the most popular dynamically typed object-oriented programming language. Structural defects due to unsafe typing occur in both of these languages. Ada83 is an object-based programming language supporting object-oriented design, and Ada95 is an object-oriented programming language. Ada83 and Ada95 are statically typed, and both support safe strong typing.

Papers have been written about the testing and dis- covery of defects in object-oriented programs [l-4]. However, a recent study [5] indicates that over 50% of common structural defects found in the structural (white box) testing of C++ code would never have occurred had the code been written in a safer programming language such as Ada83, which has a very strong typing and type checking model. Unsafe object sharing is a defect found in C++ code.

There are a number of structural errors common to

* email:drine@cne.gmu.edu

0950-5849/96/%15.00 0 1996 Elsevier Science B.V. All rights reserved SSDI 0950-5849(95)01088-2

object-oriented programming (e.g. in C++, Ada95) when objects are dynamically introduced by object pointers. Examples are (1) use of an object pointer before it is initialized, (2) reference of an object as a parent after it has through polymorphism changed to a child of the parent, and (3) various memory resource errors. A fourth (4) structural error common to many object-oriented programming languages such as C++, Smalltalk and Eiffel [6-81 occurs when an object o is shared by two owners x and y. This fourth structural error is known as the ‘sharing of objects’ structural error, and it is the focus of this paper. In general, this error can occur in programs whose language is not necessarily object- oriented, i.e. does not directly support inheritance but still supports dynamic binding.

The sharing of objects structural error is often intro- duced when, first, o is created for owner x (x points to o) and, second, x is assigned to y. Sharing can also be carried out through parameter passing by procedure calls. Object o can be created for owner x, x can be, for example, ‘read’, and x can be ‘write’ to y. If the object- oriented language does not prevent such sharing and, also does not support effective object garbage collection, then the latter deallocation of o to x may leave the allocation of o to y in place as an undesirable side-effect. Furthermore, x and y may have different security attributes which may cause one of the owners to illegally

452 D. Rinellnformation and Software Technology 38 (1996) 451-453

leak information. When multiple ownership is allowed its use should be carefully policed.

procedure Move (Origin: in out Object-Pointer; Destination: out Object-Pointer) is

begin

2. Preventing the sharing defect in Ada

Destination:=Origin; Origin:=null; end Move; __

It is easy to prevent this structural error from occur- ring in Ada83, which is object-based but not explicitly object-oriented, with its rigorous typing structure, and in fully object-oriented Ada95 (formerly called Ada9X), through the limited private type declarations framework, preventing the default assignment (or default read/write) and replacing it with a move operation. This is done in the following way.

__

procedure Display (Object: in Object-Pointer) is package New-Integer-10 is new integer_io(integer); use New-Integer-IO; begin new line;

This describes, using Ada83, how to implement Unsharable Objects. As with many object-oriented languages, Ada83 implements objects dynamically, and references them by pointers. The solution is different for Ada95

if Object=null then put (“old object no longer exists”); else put (Object.Tag); end if; newiline; end Display; __

end Unsharable_Objects;

- -This first file, having a unix file name - - ‘Unsharable_‘Objects.ada’, defines Unsharable-Objects - - so that ONLY three operations can be used with them, --namely Create, Move and Display. All implementation - -details are hidden from the package user. generic type Element is private; package Unsharable-Objects is type Unsharable is limited private; type Object-Pointer is limited private; - -Hence, the only allowable operations on occurrences - -of these two types are Create, Move and Display: procedure Create (Object: out Object-Pointer); procedure Move (Origin: in out Object_Pointer;

--This final file, whose unix file name is - - ‘Unsharable Test_Run.ada’, illustrates how to Create, - - Move and &play the unsharable objects.

with Unsharable-Objects; procedure Unsharable_Test_Run is package Unsharable_Objects_Test is new Unsharable- Objects

(integer); use Unsharable_Objects_Test; Ob: Object-Pointer; - - Represents the initial owner New_Ob: Object-Pointer; - - Represents the new owner begin - - test run Create(Ob); - - Creates an object pointed to by Ob Display(Ob); Move(Ob, New_Ob); --This operation moves the object to the

Destination: out Object-Pointer); procedure Display (Object: in Object-Pointer); private - -These implementation details are hidden enforceably from - -the user of the package. type Unsharable is record Item: Element; Tag: integer; end record;

- -new owner and destroys ownership of --the previous owner.

Display(New_Ob); Display(Ob); - -This will indicate the initial object no longer

- -exists. end Unsharable_Test_Run;

3. Alternative solutions

type Object-Pointer is access Unsharable; end Unsharable_Objects;

- - This second file, having a unix file named - - ‘Unsharable_Objects_.ada’, implements the operations - - Create, Move and Display. This is the package body of the - -abstract package specification given above, and the code is - - enforceably hidden from the package user.

. . with text-lo, use text-lo,, package body Unsharable-Objects is __

The above solution can be improved somewhat by totally hiding the type Unsharable, thus making the package specification even more loosely coupled. This alternative has been suggested by Jorge Diaz of the Soft- ware Engineering Institute [9]. He mentions that if one plans to be able to derive new types from this given type, Unsharable, then one must export it. However, this is not the case here.

Here is J. Diaz’s alternative type solution:

-_ -_ procedure Create (Object: out Object-Pointer) is generic t: Object-Pointer; type Element is private; begin package Unsharable-Objects is t := new Unsharable; --type Unsharable is limited private; < - - - delete this line Object: = t; -_

end Create; private __ . . .

D. Rinellnformation and Software Technology 38 (1996) 451-453 453

type Unsharable; --Make this an incomplete type by moving - - the record - - definition to the body (this is what is called --an “opaque” type), i.e. simply put a semi- - - colon after the type’s name.

. end Unsharable_Objects;

package body Unsharable_Objects is . .

type Unsharable is record . end record; . . end Unsharable_Objects;

The above solution as it stands does not define a class

of types. Although inheritance is possible by derived types and subtypes as in Ada83 (new operations can be added), new data elements cannot be added. The type cannot be extended by adding new data fields.

J. Diaz suggests that Ada95 can rescue us from this limitation of Ada83 in the following way. To make the type a bonafide CLASS (in the traditional object- oriented sense), one must declare it ‘tagged’ (‘tagged’ is a new Ada95 keyword), and the pointer should be a CLASS-WIDE access type as follows:

type Object-Pointer is access Unsharable’CLASS; - - Ada95

There are two additional new concepts in Ada95 that apply to the above Ada83 example, controlled types and aliased types. Controlled types allow user defined initialization after creation (constructor), finalization before destruction and adjustment after assignment. The assignment procedure can be overridden to define copy or share semantics on assignment of objects, according to William Pritchett of the CACI, Inc. Federal Team Ada [lo]. Additionally, objects that are to be desig- nated by access values must be designated by the new reserved word ‘aliased’. This documents the fact that the object is to be designated by an access type, and thus can be aliased [l 11. The bottom line, according to W. Pritchett, is that access types are more flexible in Ada95 than they were in Ada83, while still retaining Ada’s inherent ‘type safeness’, something not found in c++.

An interesting recent reference about access types (i.e. pointers) and safety and been written by Barnes [12].

Finally, because common object-oriented languages such as C++ and Smalltalk afford little protection in the language (as Ada does) for defects prevention, programming in such languages may be considered as dangerous for developing any critical systems. Ponder and Bush [13], with the assistance of David Ungar and Chris Frerking, provide additional data to show that polymorphism may be considered as harmful.

4. Conclusions

Many object-based and object-oriented programming languages have no way of directly preventing structural defects due to the sharing of objects. Languages such as C++, Smalltalk and Eiffel fall into the category of unsafe object languages where these defects can and do occur. This error can be prevented by use of object languages supporting safe, strong typing structures. Examples fall- ing into this category are Ada83 and Ada95 with their limited private, strong typing and unsharable constructs. The paper shows how unsafe object sharing is prevented using these constructs. Applications where safety and security are important should be implemented using languages in this latter category.

References

[l] R. Binder, Object-oriented software testing, Comm. ACM, 37 (September, 1994).

[2] D. Perry et al., Adequate testing and object-oriented programming, J. Object-Oriented Prog., 2 (January 1990).

[3] M. Harrold et al., Incremental testing of object-oriented class structure, Proc. 14th Int. Conf. on Software Engineering, 1992.

[4] D. Kung et al., Developing an object-oriented software testing and maintenance environment, Comm. ACM, 38 (October 1995).

[5] J. Offutt, Seminar study on structural testing defects in C++, Inf. and Soft. Systems Eng., GMU (1995).

[6] B. Stroustrup, The C++ Programming Language, 2nd edn, Addison-Wesley, Reading, MA, 1991.

[7] Goldberg et al., Smalltalk-80: The Language and Its Implementation, Addison-Wesley, Reading, MA, 1983.

[8] B. Meyer, Eiffel: The Language, Prentice-Hall, 1991. [9] J. Diaz, personal communication about Ada95, Software

Engineering Institute (SEI), CMU, 1995. [lo] W. Pritchett, personal communication about Ada95, CACI

Federal, Team Ada, 1995. [ll] Ada 95 Language Reference Manual, The Language, The

Standard Libraries, International Standard ANSI/ISO/IEC- 8652: January 1995.

[ 121 J. Barnes, Accessibility rules OK, ACM Ada Letters, 15 (Jan/Feb 1995).

[13] C. Ponder and B. Bush, Polymorphism considered harmful, Software Engineering Notes, 19 (April 1994), ACM, SIG-SOFT.