RE: [sv-bc] Mantis 2106

Gord,

Thanks.

> > 1. "Data declared in an automatic task, function, or block have the 
> > lifetime of the call or activation and a local scope. This 
> is roughly 
> > equivalent to a C automatic variable."
> > and
> > "Data declared in a static task, function, or block default to a 
> > static lifetime and a local scope."
> > 
> > I'm a little confused. Which blocks are static and which blocks are 
> > automatic?
> 
> That is dependent on the context.  In a class things default 
> to automatic.  A module is permitted to have an "automatic" 
> designation to say that routines within it default to automatic.

Well, that is not quite what the LRM says. It says,

"An optional qualifier can be used to specify the default lifetime of
all variables declared in a task, function, or block defined within a
module, interface, package, or program (see Clause 23). The lifetime
qualifier is automatic or static. The default lifetime is static."

If that is what you mean by saying that the block is automatic, OK, but
that is not the same wording used by the LRM. The LRM says that the
variables are automatic, not that the block is. I find it confusing. For
example, in contrast to tasks and functions, you can't attach the
keyword 'automatic' to the beginning of a block.

 
> > 2. "Variables declared inside a module, interface or program, but 
> > outside a task, process, or function, are local in scope 
> and static in 
> > lifetime (exist for the lifetime of the module, interface 
> or program)."
> > 
> > Earlier, static is defined as "exist for the whole simulation".
> > 
> > I think the parenthesized phrase should be deleted. It seems both 
> > redundant and wrong.
> 
> Redundant, yes.  Wrong, no.  The lifetime of an instance is 
> that of the simulation so the statements are equivalent.

Well, OK, but it does not make sense to define the same concept in two
so different ways just a few lines distant from each other. Again I find
it confusing. Why use a roundabout wording instead of a straightforward
one? So you are OK with deleting that parenthesized phrase?


> > Finally, I think the last sentence in 6.18, in the first 
> part of 2106, 
> > "It shall be an error if the type_identifier does not 
> resolve to data 
> > type, or basic data type if specified," has a grammar 
> problem. Should 
> > it be "a data type"?
> 
> Sure.
> 
> 
> > In any case, I'm not sure of the meaning. What are examples of a 
> > type_identifier resolving to a data type and to a basic data type?
> 
> The idea that Dave was trying to address (I think) 

Well, if you're not sure, then it definitely needs clarification!


> was that given:
>      typedef class C;
> "C" has a "basic data type" of "class".  So the actual type 
> definition of "C" must match the basic data type (i.e. be a 
> class).  If no "basic data type" is given in a forward, the 
> actual definition can be anything.
> 
> Perhaps this should be something like:
> 
>     It shall be an error if the type_identifier does not 
> resolve to data type.
>     It shall be an error if a basic data type was specified 
> by the forward
>     type declaration and the actual type definition does not 
> conform to the
>     specified basic data type.
> 
> I used "conform" here since I couldn't use "match".  If you 
> really feel it necessary, you could add detail to say that a 
> only a class conforms to a "class basic data type" and so on, 
> but I think the straightforward English intent here should be Ok.

That sounds much clearer.

What do you think about the reorganization of 6.21?

Regards,
Shalom
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.