[sv-bc] RE: [sv-ac] RE: 3398 and 3625

Dave,

You are correct to note that static functions preserve state, but the issue in this context is not the preservation of state, but on using such state within the function. I believe Stu expressed the intent best: a function does not use or rely on values stored from a previous call.

My earlier comments were intended to be taken in this context. Whether we want to add specific language to the LRM to describe what conditions are necessary to avoid using or relying on such state, and more specifically, what conditions must be enforced by a compliant compiler is a different issue. Note that even automatic functions may rely on static state by simply reading before writing static variables that are either declared within the function or anywhere in the design hierarchy.

Also, note that pure-DPI functions should be allowed in this context, and in that case, the SV tool must rely on the user's "pure" designation without examining the C code. It was in this spirit that the original text was written.

        Arturo

-----Original Message-----
From: Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent: Friday, June 17, 2011 8:31 AM
To: Arturo Salz; Bresticker, Shalom
Cc: Francoise Martinolle; sv-dc@eda.org; sv-ac@eda-stds.org; SV-BC; SV_EC List
Subject: RE: [sv-ac] RE: 3398 and 3625

There is no such thing as a static storage function that preserves no state information, unless it is a void function with no arguments. Not really a valid issue in the context being addressed here. The return value of a static function and all its arguments are static variables accessible via hierarchical reference.

How is the LRM supposed to express "requirements" without making explicit rules for both implementers and users to follow? I understand the difficulty in trying to explain in words that which is much easier to express in code.

Dave

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Arturo Salz
Sent: Friday, June 17, 2011 1:39 AM
To: Bresticker, Shalom
Cc: Francoise Martinolle; sv-dc@eda.org; sv-ac@eda-stds.org; SV-BC; SV_EC List
Subject: [sv-ec] Re: [sv-ac] RE: 3398 and 3625

Shalom is right to point this out. I believe the new proposal would make illegal static functions that would be legal today. For example, a static function with only input arguments that are thus overriden on each function call. Likewise, the function's output variable stores the last return value unless it is overwritten on each call. The previous verbiage was intended to allow such uses without forcing the tool to check for compliancy and instead inform users of the requirements.

- Arturo

On Jun 17, 2011, at 6:36 AM, "Bresticker, Shalom" <shalom.bresticker@intel.com<mailto:shalom.bresticker@intel.com>> wrote:

Francoise,

In the past, I have interpreted "or preserve no state information" as being a real "or", i.e., "shall either be automatic or otherwise preserve no state information", and not an additional restriction. That is, a static function that preserves no state information would be legal.

Are there automatic functions that preserve state information?

Also see Mantis 2928.

This change would affect both assertions and constraints.

Regards,
Shalom

From: owner-sv-dc@eda.org<mailto:owner-sv-dc@eda.org> [mailto:owner-sv-dc@eda.org] On Behalf Of Francoise Martinolle
Sent: Friday, June 17, 2011 3:29 AM
To: <mailto:sv-dc@eda.org> sv-dc@eda.org<mailto:sv-dc@eda.org>
Subject: [sv-dc] 3398 and 3625

I have updated 3398 with the latest versio of the proposal for nettypes. I have deleted all previous versions.
I also have submitted a new mantis item 3625 for the BC to consider to change Functions shall be automatic (or preserve no state information) and have no side effects.

to:
Functions shall be automatic, preserve no state information and have no side effects.
I wil lmake a proposal to for 3625 and ask BC to add it to the agenda of next meeting.

Francoise
       '

--
This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean.
---------------------------------------------------------------------
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<http://www.mailscanner.info/>, and is believed to be clean.
--
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.