[sv-bc] RE: [sv-ec] RE: areas of implementation divergence

Sadly, compiler directives (particularly macros) are severely underspecified in the SV LRM. For comparison, the C++ ISO standard has about 20 pages covering the preprocessor while SV has about 2 pages. Also, SV has feature of ansi-C and legacy C plus all the encryption directives. On top of that, SV doesn't specify whether compiler directives are preprocessed (many implementations do not) or when in the compilation process they are to be implemented. This area could use much improvement, but it will affair amount of work - and the likelihood of breaking legacy code is assured.

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Bresticker, Shalom
Sent: Tuesday, March 03, 2015 10:27 AM
To: Tipp, Brandon P; Brad Pierce; sv-bc@eda.org; sv-ec@eda.org
Subject: RE: [sv-ec] RE: areas of implementation divergence

Yes, ouch!

> -----Original Message-----
> From: Tipp, Brandon P
> Sent: Tuesday, March 03, 2015 20:25
> To: Bresticker, Shalom; Brad Pierce; sv-bc@eda.org; sv-ec@eda.org
> Cc: Tipp, Brandon P
> Subject: RE: [sv-ec] RE: areas of implementation divergence
> 
> 1537 in particular has caused headaches.
> 
> -Brandon
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of 
> Bresticker, Shalom
> Sent: Tuesday, March 03, 2015 11:20 AM
> To: Brad Pierce; sv-bc@eda.org; sv-ec@eda.org
> Subject: RE: [sv-ec] RE: areas of implementation divergence
> 
> Yes it does.
> 
> Typical cases are (1) that a user writes code for the tool he is using 
> and then has problems when moving to another tool; (2) user writes 
> code according to how he understands LRM and then it works differently 
> than expected or not at all.
> 
> These happen to us frequently, especially (1).
> 
> Shalom
> 
> > -----Original Message-----
> > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of 
> > Brad Pierce
> > Sent: Tuesday, March 03, 2015 20:10
> > To: sv-bc@eda.org; sv-ec@eda.org
> > Subject: RE: [sv-ec] RE: areas of implementation divergence
> >
> > Gord writes
> >
> > >As Dave said, it would take a while to go through the (many!) 
> > >implementation divergences that we know about and figure out which 
> > >the committee would consider ambiguous vs extensions/illegal 
> > >behavior.  The ones I listed above are more obviously 
> > >ambiguous/inconsistent/incomplete.
> >
> > Yet users get the job done every day. Ambiguity may be nettlesome to 
> > implementers, but does it really have a significant impact on 
> > usability?
> >
> > I'd like to hear from users about issues where tool divergence gets 
> > in the way of productivity, and whether it gets in the way more so 
> > than does the lack of requested new language features.
> >
> > -- Brad
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > This message has been scanned for viruses and dangerous content by 
> > MailScanner, 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, 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, and is believed to be clean.




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