RE: [sv-bc] E-mail Ballot: Respond by Wed Sep 05 8am PDT

I vote in favor of all except 1989, for the reasons specified below.
However, I am open to improvements, such as some of Brad's suggestions.

Shalom 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom
> Sent: Monday, August 27, 2007 2:08 PM
> To: Maidment, Matthew R; sv-bc@server.eda.org
> Subject: RE: [sv-bc] E-mail Ballot: Respond by Wed Sep 05 8am PDT
> 
> Hi,
> 
> I have some problems with 1989:
> 
> 1. It is not in the usual "CHANGE-TO", red strikeout, blue 
> addition format.
> 
> 2. There is a difference in the meaning or use of the string 
> argument to
> 
> $test$plusargs and $value$plusargs. The argument to 
> $test$plusargs is searched for literally, whereas the 
> argument to $value$plusargs is also interpreted as a format string.
> 
> The wording in 1364-2005 for these two functions was chosen 
> very carefully to be sometimes different and sometimes the 
> same. I see now that Stu made some changes in the merge. For 
> example, the 1364-2005 version had, "The $test$plusarg system 
> function searches the list of plusargs for a user specified 
> plusarg_string". In the merge, this 'plusarg_string' was 
> changed to 'string'. Probably in 1364-2005, we should have 
> changed the subclause title as well to "17.10.1 
> $test$plusargs (plusarg_string)".
> 
> But the changes proposed in this Mantis would change the 
> description of $test$valueargs without making the parallel 
> changes on $value$plusargs.
> 
> It also makes the name of the $test$plusargs argument the 
> same as that of the first argument to $value$plusargs, 
> whereas in 1364-2005, it was deliberately chosen to be different.
> 
> 3. The proposal also deletes the sentence which Mantis 988 
> added about ignoring leading nulls in the string. That may be 
> ok if the string is of type string, but I am not sure that it 
> can be left out if it is of an integral data type, such as 
> the classic reg vector.
> 
> I suggest that the editor revise this subclause to be closer 
> to the original 1364-2005 version and only then make the 
> further changes.
> 
> The rest of the changes in the Mantis proposal are acceptable 
> to me, except for their formatting.
> 
> Shalom
> 
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org
> > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Maidment, Matthew R
> > Sent: Friday, August 24, 2007 8:26 PM
> > To: sv-bc@server.eda.org
> > Subject: [sv-bc] E-mail Ballot: Respond by Wed Sep 05 8am PDT
> > 
> > 
> > -You have until 8am PDT, Wednesday, September 05, 2007 to 
> respond -An 
> > issue passes if there are zero NO votes and half of the eligible  
> > voters respond with a YES vote.
> > -If you vote NO on any issue, your vote must be accompanied by a 
> > reason.
> >  The issue will then be up for discussion during a future 
> conference 
> > call.
> > -Note: For some issues, the proposed action is captured in the bug 
> > note
> >        (resolve as duplicate, already addressed, etc.). 
> > 
> > As of the August 20, 2007 meeting, the eligible voters are:
> > 
> > Brad Pierce        
> > Shalom Bresticker  
> > Cliff Cummings     
> > Surrendra Dudani   
> > Mark Hartoog        
> > Francoise Martinolle
> > Karen Pieper       
> > Dave Rich          
> > Steven Sharp       
> > Gordon Vreugdenhil
> > Stu Sutherland
> > Alex Gran
> > Don Mills
> > Heath Chambers
> > Will Cummings
> > 
> > SVDB 910 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=910
> > 
> > SVDB 995 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=995
> > 
> > SVDB 1025 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1025
> > 
> > SVDB 1031 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1031
> > 
> > SVDB 1061 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1061
> > 
> > SVDB 1118 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1118
> > 
> > SVDB 1140 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1140
> > 
> > SVDB 1141 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1141
> > 
> > SVDB 1155 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1155
> > 
> > SVDB 1203 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1203
> > 
> > SVDB 1217 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1217
> > 
> > SVDB 1285 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1285
> > 
> > SVDB 1485 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1485
> > 
> > SVDB 1651 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1651
> > 
> > SVDB 1665 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1665
> > 
> > SVDB 1693 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1693
> > 
> > SVDB 1938 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1938
> > 
> > SVDB 1939 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1939
> > 
> > SVDB 1940 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1940
> > 
> > SVDB 1941 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1941
> > 
> > SVDB 1955 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1955
> > 
> > SVDB 1958 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1958
> > 
> > SVDB 1963 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1963
> > 
> > SVDB 1988 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1988
> > 
> > SVDB 1989 ___Yes   ___No  
> > http://www.eda.org/svdb/bug_view_page.php?bug_id=1989
> > 
> > --
> > 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.
> 

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