Re: [sv-ec][URGENT] email ballot #4, on Erratum 275, voting closes on 15 Dec 2004

From: Arturo Salz <Arturo.Salz@synopsys.com>
Date: Thu Dec 09 2004 - 10:28:40 PST

Bill,

Just a few comments on your vote, interspersed below.

    Arturo

----- Original Message -----
From: "William Paulsen" <paulsen@cadence.com>
To: "Mehdi Mohtashemi" <Mehdi.Mohtashemi@synopsys.COM>; <sv-ec@eda.org>
Sent: Thursday, December 09, 2004 8:05 AM
Subject: RE: [sv-ec][URGENT] email ballot #4, on Erratum 275, voting closes on 15 Dec 2004

> Mehdi,
>
> Three No votes with comments, and one Yes.
>
> Bill
>
>
> >
> > ===============Erratum 275, =========
> >
> > Please respond to the items in this erratum, place an X in
> > the appropriate box and place explanation for No vote.
> >
> > Errata 275 (proposal uploaded 12/8/2004, also attached)
> > item 1. The type of a single character within a string is byte
> > ____ Yes __X__ No
> >
>
> A single character should be a "byte unsigned" not just "byte", which is
> signed.
>

    The type of a string character was already a byte (certainly for reading),
    thisproposal doesn't change that. Theonly thing this proposal does is
    generalize the type of a string character for both reading and writing.
    Whether the character should be unsigned or not is a separate issue
    that is not part of this vote.

> Also, I don't like this sentence from Section 3.7, at the end of
> paragraph 4:
> "A string shall not contain the special character "\0".
>
> People using strings will expect similar behavior as in C, for example
> they might want to shorten a string by explicitly putting a 0 in the
> middle of a string.
>

    That particluar paragraph is not part of this proposal. That sentence
    is part of the previously approved erratum 334.

    Note tat SV strings are not C strings. They are dynamic objects whose
    length exactly matches the contents of the string. Truncating a string
    by writing a 0-byte in the middle of the string would requires either that
    the string contents be reallocated to match the new size or leak memory.
    This is very different from C strings. Bythe way, users can still get the
    same behavior as in C by using a byte array and manipulating the 0-byte
    terminators explicitly as done in C.

>
>
> > item 2: The putc method has only one prototype: task putc(int i,
> byte c );
> > ____ Yes _X___ No
>
> I think the blue text is confusing: It says that if the second argument
> is an "empty string" then the variable is unaffected.
>
> But "unaffected" means that the Note about being semantically equivalent
> to an assignment is confusing and incorrect - this note should be
> removed. But it could be replaced with equivalent code that does the
> checking for 0-length and 0-valued strings.
>

    Since strings cannot contain 0-valued bytes (arratum 334) then attempting
    to assign a 0-byte to a character in the middle of the string should not be
    able to change the value of an embedded character to 0.
    Therefore, the "Note" part can be removed and made mandatory.

> Also, this proposal should have examples that state if these common
> usages are legal or illegal:
>
> str.putc(i, "A");
> str.putc(i, "AB");
>
> string x = "A";
> str.putc(i, x);
>
>

    These are all governed by the conversion rules to a byte.
      str.putc(i, "A"); => OK, assigns "A" to str[i]
      str.putc(i, "AB"); => OK, assigns "B" to str[i]
      str.putc(i, x); => Not allowed. Use str.putc(i, x[0]);

>
> >
> > item 5: Typo in example, example should be modified
> > ____ Yes _X___ No
>
> The example should include this:
>
> string x = "A";
> str[j] = x; // OK or not OK?
>

    An example might be useful, but the answer is clear.
    The type of a string character is byte, thus, str[j] is a byte,
    and assigning a string to an integral type without a cast is
    not allowed (erratum 271). Therefore, the example is an error.
>
> >
> > item 8: Usage of word string: Create a new erratum
> > for this, and close 275 if all items above
> pass
> > _X___ Yes ____ No
> >
> > ================================================================
> >
> >
> >
>
Received on Thu Dec 9 10:28:24 2004

This archive was generated by hypermail 2.1.8 : Thu Dec 09 2004 - 10:28:29 PST