Language Change Specification for Repair Example in Section 23.21 Proposal

Voting Results: Cast your votes here

Yes:

1. Peter LaDow - 2016-02-16
   No:

Abstain:

1. Kevin Jennings - 2016-12-01
2. Patrick Lehmann - 2016-12-09
3. Martin Thompson - 2016-12-12
4. Ryan Hinton - 2016-12-19
5. Martin Zabel - 2017-01-19

6. Brent Hayhoe - 2017-02-16 Version 1 - Abstain due to lack of personal time for review.

Details of Language Change:

Key:

• Existing LRM text is shown in BLACK font
• Additional LRM text is shown in RED font
• Deleted LRM text is shown in RED with strike-through

LRM 23.21 page 407 near middle

void exec_proc(vhpiCbDataT cbDatap) {
    vhpiHandleT subpCallHdl, formal1, formalIt;
    int val = 0;
    vhpiValueT value;
    value.format = vhpiIntVal;
    value.value->integer.intg = &val0;
    subpCallHdl = cbDatap->obj;

     /* get a handle to the first formal parameter
         of the subprogram call */
    formal1 = vhpi_handle_by_index(vhpiParamDecls, subpCallHdl, 0);
    switch(vhpi_get(vhpiModeP, formal1)) {
       case vhpiIN:
          vhpi_get_value(formal1, &value);
          break;
       case vhpiOUT:
          vhpi_put_value(formal1, &value, vhpiDepositPropagate);
          break;
       default:
          break;
    }
}

Comments

I am unhappy about setting the integer value to an address on the stack.

1. %DEFAULT% {PeterFlake - 2017-02-08}

The LRM is not explicit for the given example since it does not give the corresponding subprogram signature. Regardless, neither the original nor the edit are correct. Nor is the example particularly meaningful for the vhpi_put_value case

Now, based on the type, 'vhpiIntVal' this is a subprogram where the first formal parameter is an integer, something like:

procedure myproc(variable val : in integer);

In the orignal, the 'value' union in 'vhpiValueT' does not have a member named 'integer'. And in the edit, 'intg' is an int, not an int*. The local 'val' is not necessary, but if one wanted to be explicit, one would do 'value.value.intg = val;'

(As a side not, there are '*s' versions, such as 'intgs' which are pointers. But these are used for array of values. So if the formal were an array of integers, the format would be vhpiIntVecVal and intgs would be used. In that case, a pointer to an array of integers is necessary. And it is safe to use value allocated on the stack.)

The addition of the 3rd argument to vhpi_put_value is appropriate (though vhpiDepositPropagate is only meaningful if the formal is a signal--the missing subprogram signature would make this more clear).

I'm not sure if I can edit the change directly, or if the original LCS author should do so.

-- Pete LaDow - 2017-02-13