Clarification: the use of a non- shared qualified operand of upc_blocksize (and related operators) is erroneous

[Former user]

Originally reported on Google Code with ID 60 ``` This question arose in the following discussion: http://code.google.com/p/upc-specification/issues/detail?id=3#c24

In that issue, the following aspects of the UPC and C99 specification were noted.

-----

The C99 specification in Section 4 ("Conformance") states:

4. Conformance 1 In this International Standard, ‘‘shall’’ is to be interpreted as a requirement on an implementation or on a program; conversely, ‘‘shall not’’ is to be interpreted as a prohibition. 2 If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe ‘‘behavior that is undefined’’.

The UPC 1.2 Specification lists the following _constraint_ under section 6.4.1.3 ("The upc_blocksizeof operator").

1 The upc blocksizeof operator shall apply only to shared-qualified expressions or shared-qualified types. All constraints on the sizeof operator [ISO/IEC00 Sec. 6.5.3.4] also apply to this operator.

Given the use of the term "shall" within a constraint, does the specification not already require that the argument of upc_blocksizeof must be a shared qualified expression. Thus, any other usage is an error?

In the C99 specification, 'sizeof' lists this constraint:

1 The sizeof operator shall not be applied to an expression that has function type or an incomplete type, to the parenthesized name of such a type, or to an expression that designates a bit-field member.

Is the use of 'shall not' some how a stronger restriction, and therefore a prescription that these excluded cases are definitely erroneous uses, but the "shall" language of the UPC speicification is somehow more permissive?

If that is the case (and interpretation), I would like to see the UPC specification amended to use the "shall not" form of description, and will submit a separate tracking issue to discuss that proposal. Otherwise, it seems to me that this erroneous use case is already covered.

-----

5.1.1.3 Diagnostics

1 A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a preprocessing translation unit or translation unit contains a violation of any syntax rule or constraint, even if the behavior is also explicitly specified as undefined or implementation-defined. Diagnostic messages need not be produced in other circumstances.

Per above, doesn't the specification require that a UPC compiler issue a diagnostic if the operand of upc_blocksizeof is not a shared qualified expression?

```

Reported by `gary.funck` on 2012-07-02 18:15:40

[Former user]

``` I agree that Gary is correctly interpreting the conformance language. So, by my reading the current specification required a diagnostic for upc_blocksizeof(MYTHREAD) (as an intentionally stupid example). However, I don't think we need to provide explicit language in the UPC spec for every point that a diagnostic is required. That is the purpose of Section 4.

This gives, I think, four options:

1. Agree that a diagnostic should be required, and IS required by existing language, leaving the spec unchanged 2. Agree that a diagnostic should be required, and that more language is needed to clarify this 3. Agree that a diagnostic is NOT desired, and "weaken" the specification for upc_blocksizeof() to avoid requiring one 4. Agree that a diagnostic is NOT desired, and modify the specification for upc_blocksize() to define behavior of non-shared-qualified arguments ```

Reported by `[e-mail]` on 2012-07-02 18:41:42

[Former user]

Reported by `gary.funck` on 2012-07-03 15:07:12 - Labels added: Type-Clarification - Labels removed: Type-Defect

[Former user]

``` The violation of 'shall' requirement in a constraint means a diagnostic is required. I believe this is already quite clear from C99.

I do not believe C99 places any difference in priority or emphasis on the phrase "shall" versus "shall not" - breaking either one has the same consequences, it's simply a matter of clarity to choose one or the other for a given situation.

Move to close with NoChange. ```

Reported by `danbonachea` on 2012-08-13 04:48:10

[Former user]

``` I agree with the "NoChange" disposition, but will point out that this issue was created because there appeared to be difference of opinion on the interpretation of the UPC specification as to whether/not a conforming UPC compiler should issue a diagnostic or not on attempts to apply upc_blocksizeof (and associated unary operations) to non- UPC shared types or expreesion.

If there is still disagreement on this point, now would be a good time to note it, prior to this issue ticket being closed.

```

Reported by `gary.funck` on 2012-08-13 16:02:53

[Former user]

``` Set default Consensus to "Low". ```

Reported by `gary.funck` on 2012-08-19 23:26:19 - Labels added: Consensus-Low

[Former user]

``` Seem to have high consensus that nothing is required to be changed here. ```

Reported by `danbonachea` on 2012-09-17 18:24:26 - Status changed: `NoChange` - Labels added: Consensus-High - Labels removed: Consensus-Low