[sv-cc] Questions on 205 and 278/279

The language used to specify the packed array declaration macros
in E.9.2 leads to the erroneous code for Example 3 in E.9.4 as
Francoise notes in 278/279. In order to use the functions in
E.9.1.4 as intended, the types defined by the macros in E.9.2 must
not produce types that are arrays. If they do, then the code in
E.9.4 will index the wrong dimension (indexing the packed dimension
rather than the unpacked), and be unable to transform from actual
to canonical. It will instead translate garbage to canonical form.

Suppose we were to modify the text of E.9.2 from:

    The actual definitions are implementation-specific. For example,
    a SystemVerilog simulator might define the later macro as
    follows:

    #define SV_LOGIC_PACKED_ARRAY(WIDTH,NAME) \
      svLogicVec32 NAME [SV_CANONICAL_SIZE(WIDTH)]

to:

    The actual definitions are implementation-specific, but must
    not define an array type (see definition in ISO 9899-2001 clause
    6.2.5). For example, a SystemVerilog simulator might define
    the later macro as follows:

    #define SV_LOGIC_PACKED_ARRAY(WIDTH,NAME) \
      struct { svLogicVec32 __unnamed [SV_CANONICAL_SIZE(WIDTH)]; } NAME

Would this definition be a satisfactory resolution to the problems
of Example 3 in E.9.4? Or am I erroneously interpreting E.9.4 as an
expected use model for svGetBitVec32()?

The alternative to this change is to flip the order of specification
for unpacked and packed dimensions. I think that is part of the
proposal for 205. As I see it, that would create a usability
problem in matching SystemVerilog types with C types. The above
macro permits the C declaration to record the packed dimension
first, followed by the name, and finally by the unpacked dimensions.
Was this an intentional design decision? If so, then changing the
declaration pattern to make the packed dimension the most rapidly
varying one would be a significant change.

Can someone on the reflector fill in the details on these questions?
It would be helpful for the committee to be clear on these issues
before voting on 205 and/or 278/279.

/sjd
Received on Tue Nov 2 13:56:49 2004