Add description of semantics of sizeof applied to a UPC shared type or expression in a static THREADS environment

[Former user]

Originally reported on Google Code with ID 16 ``` This proposal is responsive to issues 36 and 37.

36. Is sizeof() allowed to return a non− integral compile−time constant value? It certainly must do that in a dynamic THREADS environment.

37. What does C99 say about sizeof()? Can the value be computed at run−time? Must the returned type be size_t? Is size_t even mentioned in C99? Can it return a suitably sized type, that may for example be bigger than size_t? -- See Section 6.5.3.4 of C99. sizeof can be applied to VLAs, so it can be computed at run-time. The return type must be size_t and that type is declared in stddef.h.

In section 6.4.1.1 the UPC language specification states.

The sizeof operator will result in an integer value which is not constant when applied to a definitely blocked shared array under the dynamic THREADS environment.

Regarding point 36 above, the current language in the UPC specification seems sufficient because it explicitly states the value is "not constant". Perhaps the missing piece is that the specification does not state explicitly the semantics of sizeof when applied to shared types or expressions in a static THREADS environment. Strictly speaking, the C99 standard sizeof semantics cannot simply be inherited here, because C99 does not define the "shared" qualifier.

Regarding point 37 above, the current language in the UPC specification does state the value can be non-constant in the dynamic THREADS environment. If the proposal in issue #13 is accepted, then no new additional 'upc_size_t' type will be defined, thus answering that aspect of the question. And as discussed in point 7, the C99 spec. already states that the value returned by sizeof is of type size_t defined in stddef.h.

Proposal:

Add additional text in the definition of sizeof applied to a UPC shared type or expression when applied in a static THREADS environment. These semantics should be consistent with sizeof applied to a regular "C" type or object that does not reference a variably modified type or object.

Accept issue #13, and do not define a new type that extends the range of values beyond those delimited by size_t.

```

Reported by `gary.funck` on 2012-05-21 00:59:41

[Former user]

``` I agree w/ Gary:

1) Add clarifying language indicating that in a static threads environment the behavior of sizeof() is consistent with that for "regular C" types and objects with compile-time constant array dimensions. 2) Do not introduce a new type ```

Reported by `[e-mail]` on 2012-06-01 05:01:40 - Labels added: Spec-1.3

[Former user]

Reported by `[e-mail]` on 2012-06-01 06:05:41 - Labels added: Milestone-Spec-1.3 - Labels removed: Spec-1.3

[Former user]

``` From one perspective, we might mark this as "no change", because in spirit sizeof applied to shared types behaves in a similar fashion to sizeof applied to non shared-qualfieid types.

This note argues in favor of providing additional detail: "Perhaps the missing piece is that the specification does not state explicitly the semantics of sizeof when applied to shared types or expressions in a static THREADS environment. Strictly speaking, the C99 standard sizeof semantics cannot simply be inherited here, because C99 does not define the "shared" qualifier."

If you do not agree with the proposal above, and would suggest for example that no change is required, please post your reasoning in a follow up reply to this issue.

```

Reported by `gary.funck` on 2012-06-28 20:10:12

[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]

``` I will retain ownership of this issue. ```

Reported by `gary.funck` on 2012-09-19 17:04:31

[Former user]

``` Per the 9/21 telecon, this issue awaits further wider review.

```

Reported by `gary.funck` on 2012-09-22 18:02:12

[Former user]

``` Here are the ISO C99 semantics for sizeof 6.5.3.4: "P2: The sizeof operator yields the size (in bytes) of its operand, which may be an expression or the parenthesized name of a type. The size is determined from the type of the operand. The result is an integer. If the type of the operand is a variable length array type, the operand is evaluated; otherwise, the operand is not evaluated and the result is an integer constant.

P3: When applied to an operand that has type char, unsigned char, or signed char, (or a qualified version thereof) the result is 1. When applied to an operand that has array type, the result is the total number of bytes in the array.84) When applied to an operand that has structure or union type, the result is the total number of bytes in such an object, including internal and trailing padding."

and the clarification added by the current UPC 6.4.1.1 language:

"The sizeof operator will result in an integer value which is not constant when applied to a definitely blocked shared array under the dynamic THREADS environment."

The C99 verbiage already seems comprehensive and completely applicable to UPC types, regardless of shared - "the size (in bytes) of its operand" is a well-defined concept that is completely independent of whether an object or type happens to be shared-qualified. The clarification in 6.4.1.1 exists solely to add one more case to the last sentence of ISO C P2 where the result is not "an integer constant".

It sounds like this issue is arguing for a clarification of the form "in all other cases, sizeof() behaves exactly as specified in ISO C". However, clarifications of this form are redundant and already covered by UPC Section 1:

"All C specifications as per ISO/IEC 9899 [ISO/IEC00] are considered a part of these UPC specifications, and therefore will not be addressed in this document."

The UPC spec is kept concise and focused by operating under the regime "C99 rules apply everywhere, unless otherwise noted", and I think we should avoid re-stating C99 rules whenever possible, unless some UPC feature implies a non-obvious interpretation, which does not appear to be the case here.

Move to close with NoChange. ```

Reported by `danbonachea` on 2012-09-24 23:33:23

[Former user]

``` On the 10/5 telecon it was agreed this issue is resolved with NoChange. ```

Reported by `danbonachea` on 2012-10-07 06:22:18 - Status changed: `NoChange`