Re: [sv-ec] $cast a null expression

Some comments below.

On 11/21/2010 2:26 PM, Jonathan Bromley wrote:
> hi EC
>
> Last meeting we talked about how $cast should behave when its
> first (target) argument is a class handle variable, and its
> second (source) argument is an expression whose value is null.
> I've created Mantis 3293 to capture this.
>
> Given the increased complexity introduced here by the multiple
> inheritance proposals, I'd be glad to know what behaviour
> people think is desirable before I put any effort into a
> proposal. It seems to me that there are several situations:
>
> - If the source expression's statically determined type is a
> descendant of, or equivalent to, the target type, then a
> simple copy would be OK so it seems reasonable for the
> $cast to succeed unconditionally, and be compiled as a
> simple copy operation - so it would succeed if the source
> is null, too. Current tools have $cast succeed if the
> source is null, in this case.
>
> - If the source expression's statically determined type is
> on a different branch of the hierarchy from the target's,
> then in SV-2009 the cast is sure to fail; having it succeed
> if the source happens to be null sounds unsatisfactory to me.
> However, if we have multiple inheritance then things are not
> so simple; the cast is no longer sure to fail, but I would
> guess that it should still be an error if the source is null.
> Current tools disagree about this already.
>
> - If the source expression's statically determined type is
> an ancestor of the target's, what should happen if the
> source is null? Current simulators all say "cast succeeds",
> but is this correct?
>
> - If the source expression is the special value "null", should
> the rules be any different than if the source is some other
> expression that happens to give a null value?

I think that it probably should. The rules from 11.4.11 are
for conditional expressions are more flexible about the
literal null.

My opinion is that the literal null is a "universal null" but
no other null is. So assigning a null from a virtual
interface to class should always be illegal. Essentially
what I'd like to see is that assignment of a "literal null"
is very flexible and assignment of something holding
a null behaves as if there were a possible non-null for
which the assignment would be legal. So up/down
casting *in the same inheritance hierarchy* would be
Ok since there would be a feasible non-null. But casting
to unrelated classes would be illegal. In a non-MI
scenario this is easy to check -- if either type is a super
type of the other, the cast is legal for a null otherwise
it isn't.

In an MI situation, this is a bit nastier to check since
there any subtype of either class could "unify" the
two and make the cast legal. So we might want to
think about whether we want to go that route for
MI.

>
> Finally, can someone kindly remind me about this subtlety, which
> I seem to remember was dealt with for 2009 but I can't find the
> relevant Mantis. Given these declarations:
> class C; ...
> class D extends C; ...
> C c;
> D d;
> bit b;
> what do we say about the data type of this expression?
> b ? c : d
> Is d effectively upcast to C before being returned, so the
> expression as a whole has type C?

Yes; from 11.4.11:
     e) else if the first expression and second expression are of a
class type deriving from a common
         base class type, the resulting type is the closest common
inherited class type.

That would be "C" in this case.

Gord.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.