Clarification: cast of (shared <type> * shared) is an error

[Former user]

Originally reported on Google Code with ID 74 ```

Cast of (shared <type> * shared) is an error according to one reading of the specification, but the specification language could be improved to definitively state this rule.

The second 'shared' applies to the actual pointer value itself, not the pointer component type.

In version 1.2 of the UPC specification 6.4.3p1 (constraints) states:

A shared type qualifier shall not appear in a type cast where the corresponding pointer component of the type of the expression being cast is not shared-qualified.[9] An exception is made when the constant expression 0 is cast, the result is called the null pointer-to-shared.[10]

The implication here is that 'shared' can only be used in a cast as a qualifier to the component type of a pointer-to-shared type.

This dis-allows:

shared int x = 1; shared int y = 2; shared int * shared p;

int main(void) { if (MYTHREAD == 0) { x = (shared int) y; Error p = (shared int * shared)&x; Error } return 0; }

GUPC issues the following errors:

shared-cast.upc:9:8: error: UPC does not allow casts to a shared type x = (shared int) y; Error ^ shared-cast.upc:10:8: error: UPC does not allow casts to a shared type p = (shared int * shared)&x; Error ^

Some vendor compilers may currently accept either or both casts without complaint.

```

Reported by `gary.funck` on 2012-07-18 00:01:01

[Former user]

``` This is just a more complicated version of issue 75, and I believe the same argument applies.

Top-level type qualifiers on values are always completely meaningless, and the top-level shared qualifiers in the cast of both x and y are meaningless. If you replace the top-level "shared" qualifier with "const", it remains equally meaningless (but harmless and permitted). The quoted language from the UPC spec was intended to constrain the appearance of shared qualifiers as NON top-level qualifiers in type casts.

Now granted, a user who has written this meaningless type qualifier in his cast is probably confused, and a warning might be justified to inform him of his confusion. But as it is harmless, I see no reason to prohibit it.

```

Reported by `danbonachea` on 2012-08-03 14:20:07

[Former user]

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

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

[Former user]

``` Change Status to New: Requires review. ```

Reported by `gary.funck` on 2012-08-19 23:37:41 - Status changed: `New`

[Former user]

``` Take ownership from Gary. I will summarize this issue in the next telecon. ```

Reported by `[e-mail]` on 2012-09-17 21:17:10

[Former user]

``` Summary: I agree with Dan in Comment 1 that this is essentially the same issue as Issue 75. And we should treat this issue consistently with Issue 75.

My recommendation is to close this issue without changes. ```

Reported by `[e-mail]` on 2012-09-20 18:30:40 - Labels added: Priority-Low - Labels removed: Priority-Medium

[Former user]

``` As I noted in Issue 75:

By leaving as "no change", this means that there is nothing in spec, except by inheritance of the C99 spec, and then by extension of C99's handling of qualfiiers that we can arrive at the conclusion that this sort of cast is allowed.

I'd like to see something more helpful here: something in "Semantics" or something in an example, for example.

```

Reported by `gary.funck` on 2012-09-20 20:10:34 - Labels added: Priority-Medium - Labels removed: Priority-Low

[Former user]

``` "this means that there is nothing in spec, except by inheritance of the C99 spec"

This inheritance is the general form of the UPC spec, so I don't really see specification-by-inheritance as a problem. C99 6.5.4 states:

"A cast does not yield an lvalue. Thus, a cast to a qualified type has the same effect as a cast to the unqualified version of the type."

which already seems very clear and directly applicable to UPC. Thus the cast (shared int) "has the same effect" as the cast (int) and there is no error. In this case, shared really is "just another type qualifier" and inherits the C99 rule for qualifiers in casts. I don't see the value of re-stating the C99 rule, perhaps we can just add this to the rationale doc?

```

Reported by `danbonachea` on 2012-09-20 21:48:56

[Former user]

``` In principle, I support the minimalist approach of placing no more in the UPC spec. than is needed, and certainly by a reasonable interpretation the current specification does that with respect to the cited use case.

I will simply repeat my request:

"I'd like to see something more helpful here: something in "Semantics" or something in an example ...".

Although "shared" is defined as a qualifier, it has some unique properties that in some ways resemble storage specifiers (like "auto" and "static") because "shared" in a variable declaration designates a "scope" that spans UPC threads. I am probably not saying this in the most succinct and technically accurate way. In any event, because "shared" has some unique properties that are distinct for UPC, I personally would like to see areas like this clarified in the specification.

Certainly the position has been taken on other similar issues that clarifications like this should be relegated to a UPC Rationale document. Perhaps if I knew that the Rationale document were to be released with the version 1.3 UPC language specification document I would view that approach as sufficient. Probably, though, I would still prefer that the spec. is clearer and more explicit in defining that gratuitous casts to shared like those in this issue and Issue 75 are valid and allowed.

```

Reported by `gary.funck` on 2012-09-21 03:57:17

[Former user]

``` In the last telecon, the attendees agreed that this was essentially the same issue as Issue 75, as explained in Comment 1. We will handle this issue the same as Issue 75.

For reference, the resolution for Issue 75 is "No change to the UPC Spec document and Add clarification and examples in the Rationale document." ```

Reported by `[e-mail]` on 2012-10-01 17:07:52 - Status changed: `NoChange`