Clarification: UPC library functions can be implemented as macros, but must also have external linkage

[Former user]

Originally reported on Google Code with ID 18 ``` This issue is partially responsive to open issue 41, and generally applies to all UPC library functions.

41. Are there advantages to defining certain library functions such as upc_threadof, upc_phaseof, and upc_addrfield as unary operators rather than functions/macros defined in the core library?

The relevant section of the C99 standard is 7.1.4.1 "Use of library functions":

Any function declared in a header may be additionally implemented as a function-like macro defined in the header, so if a library function is declared explicitly when its header is included, one of the techniques shown below can be used to ensure the declaration is not affected by such a macro. Any macro definition of a function can be suppressed locally by enclosing the name of the function in parentheses, because the name is then not followed by the left parenthesis that indicates expansion of a macro function name. For the same syntactic reason, it is permitted to take the address of a library function even if it is also defined as a macro.

Thus, in response to issue 41, if we assume that the various shared pointer manipulation functions are implemented as macros, they must also be implemented as functions with external linkage, so that '&' is defined for the purpose of taking the address of these library functions.

```

Reported by `gary.funck` on 2012-05-21 16:11:01

[Former user]

``` I agree with Gary that IFF we don't take any action, then these functions are automatically required by the C99 standard to have versions with external linkage.

We are, of course, free to do any of the following if we wish: + Make them non-functions (see issue #19) + Clarify, as this issue asks, that they must have external linkage versions + Add text to explicitly exempt them from the requirements of C99 7.1.4.1

I can think of nothing compelling to help me decide among these options. ```

Reported by `[e-mail]` on 2012-05-22 00:07:36

[Former user]

Reported by `[e-mail]` on 2012-06-01 03:54:07 - Labels added: Spec-1.3

[Former user]

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

[Former user]

``` If issue #19 makes them operators, this issue is moot.

Otherwise, I see no compelling reason to exempt them from the external linkage requirement. I do not think we should add clarifications that simply restate rules clearly imposed by C99, because that is a slippery slope that ends up sucking in the entire C99 spec. ```

Reported by `danbonachea` on 2012-06-14 23:51:15

[Former user]

``` Dan wrote:

If issue #19 makes them operators, this issue is moot.

Not so. This issue begins with [emphasis added]: This issue is partially responsive to open issue 41, and GENERALLY APPLIES TO ALL UPC library functions. And thus this issue "survives" any resolution of issue #19, applying for instance to the allocation and lock function, the collectives and I/O extensions, the proposed timers, etc..

I do not think we should add clarifications that simply restate rules clearly imposed by C99, because that is a slippery slope that ends up sucking in the entire C99 spec.

I agree on that point - we "include by reference" all of C99 and thus should not be forced to repeat it or cite every relevant passage. However, IF others feel strongly about needing it, I would not be opposed to a single sentence for clarification near the beginning of the spec. Something like "All library functions defined in this specification are subject to 7.1.4.1 of [ISO C99 reference]" ```

Reported by `[e-mail]` on 2012-06-15 00:02:53

[Former user]

``` When I filed this "Clarification" issue, it was simply to document a point that is implied by inclusion of the C99 standard, but that might be easily missed by UPC library implementers. The intent of other "clarification" issues is similar: to record the stated interpretation of the standard, to solicit consensus, and to provide an issue ticket which can track proposed changes to the specification (if there is consensus that some change is required).

In that context, as long as we have consensus that every UPC library function must at least have external linkage, but can also be implemented as a macro, then I agree that we need no additional language that simply re-states the relevant parts of the C99 specification.

```

Reported by `gary.funck` on 2012-06-15 01:59:23

[Former user]

``` Nobody else has commented on this issue and the three of us seem in agreement that no spec action is required, so marking it closed. ```

Reported by `danbonachea` on 2012-06-15 02:05:23 - Status changed: `WontFix`

[Former user]

``` Mass update to closed issue status ```

Reported by `danbonachea` on 2012-06-15 18:40:32 - Status changed: `NoChange`