Generalizations and Practical Considerations

In order to simplify what has been presented so far, certain assumptions were made which are too restrictive in practice. These are that the aliases have already been found and all lie within a single allocated object o, and that only changes to type definitions occur and not changes to variable declarations. Structure types were assumed to be defined in terms of a single unit scalar with no alignment requirements and no fields deleted. Finally it was assumed that the word moping

W can be automatically defined in terms of a field mapping M, This section indicates how the algorithm and conditions presented can be generalized to cope with relaxation of these assumptions. The dynamic modification mechanism in Testbed contains these generalizations.

7.6.1 Arrays

Arrays may be considered as a subclass of structures, for which all the fields have the same type. In the implementation they are treated specially for efficiency

reasons as it is not necessary to represent an array with a separate type descriptor

7.6.2 Different Scalar Types

In practice scalar types may not have the same size but can be modelled by choosing some common unit of size (such as the byte) and defining larger types to be structures consisting of a number of these units. If alignment is required, then the location function L can be defined to take this into account. In practice simple byte copying with rearrangement will not be sufficient In this case special conversion functions need to be defined for mapping between scalar types, such as integer to real conversion.

7.63 Pointers in Aliases

So far the pointers which represent aliases have been considered as separate from

the data, but they are actually part of it and need to be converted. This happens after the conversion of the rest of the data. Pointers are initially copied from the

old to new versions of variables and then updated with the new values computed using the algorithm given above. An additional form of inconsistency may arise when an alias contains a pointer which is not present in the host object. Since the

data is only converted using the real object’s type conversion, the pointer wUl not be updated. This situation may be added as an extra consistency constraint to be checked.

7.6.4 Deleted Fields

It may well be desirable to be able to delete fields from structures. This situation is dealt with by introducing a special null value (_L) into the ranges of the mapping functions W and M. The algorithm must be modified to cope with the situation where the start of an alias x is located in a field which is deleted from the real object. In this case if the first non-deleted field of x corresponds to a deleted word in o, then either the algorithm can be aborted or the new address of the alias can be set to an invalid value which will show up in the word consistency test. Otherwise

A'{x) is computed from the image of the first word in the first non-deleted field of

X .

7.63 Extending the Retype

So far the assumption has been made that the new type of an object is exactly that corresponding to the retype. Similarly it was assumed that the retype had the property that the new type of a field was that given by retype for its original type. These assumptions were made to simplify the notation and the algorithm.

In general it is desirable to relax them and allow Wt,, and Mt,, : [0, n) [0, |s|), where n is the number of fields of to be defined for some cases when s ^ t'.

Consider Figure 7.9. Here it is assumed that the sub type does not change and Old Type (t) Variables New Type (t’)

typedef struct ( scalar x,y; ) sub; typedef struct { scalar a; sub b; ) info;

info block; typedef struct

{ scalar y,x; ) bus; typedef struct { scalar a; bus b; } info; 1 a b a b

Figure 7.9: Extending the retype.

that the new type bus has been introduced. The b field in in f o' has type bus. The b field is to be mapped so that the subfields with matching names correspond, i.e., xi->x and yn+y. This would work if were defined manually as:

M,■nb (1, 0).

However, there may be other variables of type sub or with fields of that type

which retain this type in the new version. Since the sub type is not changed, the above definition of M^b would be wrong for these variables. An extra mapping is needed:

Mxvib,ham ~ (1, 0)'

In order to define using this mapping instead of M„b,.ub', some way of indicating the destination type of a field when mapping between a particular pair

of types is needed. To this end the local retype Rt,, : [0, n) T is defined. Then the general version of the word moping is defined as:

w,Ap)

_\

»(p) -I- — 4 ( 0 ) , if 4 ( 0 < p < Lt{i + 1) The generalization of the F function of Section 7.4 is:

Ft,,{i)==lMt„{i)yMt„(i)-^\Rt,,{i)\y

Conditions (7.4a) and (7.4b) generalize in an obvious way and Proposition 7.15 and Theorem 7.16 and their proofs are similar.

As with the simpler case, the definition of Mt,, may be automated by matching fields with like names or done manually where this does not work. The local retype can be defaulted for pairs {tyP) given by the retype to Rt,f{i) ~ (Uy* but this can be overridden and extra mappings provided as required. Returning to Figure 7.8, the local retype would be:

Ria£o,ixto* = (scalar, sub).

Note that the local retype of the b field is sub, not sub', so the resulting IPinf o' is the desired one even if the sub type is redefined.