Re: Minutes from John

Per,

A few comments ...

Per Bojsen wrote:

> Hi Shabtay and John,
>
> regarding the excerpt of Section F.8.3:
>
>> _There are functions that allow the user to retrieve and manipulate 
>> the current operational scope. It is an error to use these functions 
>> with any
>> C code that is not executing under a call to a DPI context imported 
>> task or
>> function._
>
>
> It seems to me this section talks about a specific subset of the
> utility functions, namely those that `retrieve and manipulate the
> *current* operational scope'.  This would include
>
>   svGetScope()
>   svSetScope()
>
> However, the rest of the utility functions does not seem to be covered
> by that paragraph:
>
>   svGetNameFromScope()
>   svGetScopeFromName()
>   svPutUserData()
>   svGetUserData()
>
> All these do not necessarily manipulate the current operational scope.
> I think it is these four that would be really useful to have.  I still 
> think
> the SV standard is at best ambiguous as to whether these are allowed
> outside an imported function context.  From an implementation point of
> view I have a hard time justifying why these could not be easily 
> implemented
> such that they work anywhere.

johnS:
Generally I think I agree with this. And, in light of the newly reworded
LRM text relaxing illegality of the utility functions in non-context
imports I would go on to say that even svGetScope() is generally
harmless and would not, in and of itself lead to side effects - which
I think is the general concern of what can happen in non-context functions
when vendors want to optimize by removing "instrumentation" or
"infrastructure" that would normally be required for context imported
functions.

svSetScope() is probably the only one we really have to be
careful with.

>
> I know the last paragraph on p. 585 (section F.8) does seem to forbid
> all of these functions, although it is also vague because they just talk
> about a `small set of utility functions' without being specific about
> what they are.  In any event, this paragraph could be seen as conflicting
> with the paragraph from Section F.8.3 depending on how you interpret
> the text.

johnS:
So, now as you see from today's e-mail to Shabtay this is no
longer the case. Now these functions have "undefined" rather
than "illegal" effects so hopefully we can provide some more specific
definition here.

>
> In summary, I think Shabtay's idea of talking some more to the SV gurus
> is a good idea here.  This text ought to be clarified.  Ideally it should
> explicitly state that the four functions I listed above should be
> callable from anywhere. svGetScopeFromName() may have to be restricted
> to after elaboration, which automatically restricts the others since you
> wouldn't be able to get a scope before elaboration anyway.

johnS:
It is probably the case that we in the ITC should take a stab at making
a strawman proposal here, then submitting to some of the gurus on
other committees to review.

-- johnS
<eom>

>
> Per
>
>
>

-- 

This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________