Black-box composition of mismatched software components

236 E.3. Cake’s tolerance of imprecision
for later retrieval. This means that if we encounter a less precise pointer subsequently,
we are nevertheless sure to have a precise solution.
A tentative idea for addressing difficult cases is exploiting “previously seen” in an expensive
but powerful manner. By scanning the stack and static storage, we can potentially
discover other pointers into the heap object than the input pointer or those previously
seen. It is likely that one of these is precisely typed. Therefore, if the analysis fails, we can
force such an analysis—perhaps piggy-backed on top of a garbage collector, as proposed
for various other dynamic analyses [Reichenbach et al. 2010]—until it hits such a pointer.
Although expensive, this cost is potentially greatly amortised, because the collector may
discover precisely-typed pointers for many other objects at the same time.
E.3 Cake’s tolerance of imprecision
The analysis we have shown so far is clearly imprecise. In many cases, however, the Cake
language can tolerate imprecision.
When using array length constraints, the analysis is effectively redundant: the Cake
programmer has given us both a precise element type and a precise array size. Therefore,
it doesn’t matter if the analysis doesn’t yield a unique answer—all the Cake runtime
needs to know is how much of the heap block to apply correspondences to, which is a
given. Note, however, that in practice it may also yield a precise typing for the whole
block—e.g. in the example, where perhaps few or no other types contain an array of 16
chars, hence allowing the deduction that the block is a FooWidget[3]—and this should be
remembered for future use. This will not succeed in some cases, however: for example, if
the programmer only wants to pass the first 8 characters to the called function, out of a
larger string, the analysis will not discover any typings.
Another case is where the pointed-to object is of an opaque or shareable type—in this
case, the runtime does not care whether the analysis is ambiguous. Rather, the pointer
can be given to the receiving component as-is, with no need to copy and convert any
data. For example, if a char* is passed and this yields an ambiguous typing for the block
(say, it might be one big array of chars or a pointer into some smaller, contained array
of chars), this does not matter so long as char is shareable with the receiving component.
Similarly, uncorresponded types are effectively opaque so the runtime need not apply any
correspondences.
Similarly, if no admissible reinterpretation could reach a more specific type of object
for which different Cake correspondences are defined than for the imprecise type, then
the imprecise type suffices. For example, if no Window rules are defined, nor rules for
any other type containing Widget, then knowing that the pointed-to object is a Widget
suffices for making the appropriate rule selection..
If the analysis fails, Cake issues a run-time warning and proceed with an imprecise
result. Even in cases beyond those enumerated above, this does not always result in
incorrect behaviour. (In short, this is because even if it would be admissible to reinterpret
the pointer to some containing type, this need not happen in any given execution.)