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

> -----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 4:08 AM
> 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.
[DR] I have been using this format for years. In a large proposal, it is
not useful to repeat the original text. Are the strikeouts not red and
the additions not blue?
> 
> 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.
[DR] Unless you have a better suggestion, I will take those changes out
of this proposal so all the rest of the changes can applied. I can
create a new mantis item for this. (but I'm not volunteering)
> 
> 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.
[DR] Now that these arguments are defined as strings, the implicit
conversion of an integral value to a string will remove leading \0's.
See 7.8
> 
> 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.