Clarification: Inclusion of <upc.h> is not required for strictly conforming UPC programs

[Former user]

Originally reported on Google Code with ID 56 ```

It has been my understanding that every well-formed UPC program must have a "#include <upc.h>" in it. I had preseumed this requirement was to give impelementations a "hook" where they can define pre-defined macro values and perform various other actions that are required to implement UPC.

Is the inclusion of <upc.h> required in strictly conforming UPC programs?

If required, is this this stated in the 1.2 UPC specification?

The discussion of <upc.h> begins at section 7.2, "UPC utilities <upc.h>". There, <upc.h> appears to be discussed only as needed to include the prototypes required to define the various core library functions. Based upon a quick review, I didn't find any references that indicated that all UPC programs are required to have a "#include <upc.h>".

```

Reported by `gary.funck` on 2012-06-29 18:12:29

[Former user]

``` My view on this matches Gary's pretty closely as far as I can tell.

I have, until relatively recently, always started every UPC source file with #include<upc.h> as a matter of course.

I only more recently realized that lacking any calls to upc_* functions or use of upc_* types, there was no actual NEED for upc.h on any of the implementations I was using (THREADS and MYTHREAD "just work" w/o it). However, I have not seen any "last word" stating that inclusion of upc.h is or is not required in a conforming application.

Assuming the issue is not already settled by some existing spec language that Gary and I have both missed, I have no strong feelings on whether or not we should require inclusion of upc.h by all conforming UPC applications.

I am in favor of having whatever we decide made clear in the text of section 7.2 (even if it also appears elsewhere). ```

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

[Former user]

``` Including upc.h at the top is certainly common practice, but it seems a bit sketchy to "require" inclusion of a particular header file in order for the translation unit to be conformant UPC - especially since file inclusion is handled by the preprocessor so early in translation, and is completely orthogonal to all other aspects of syntactic correctness.

I don't think it's a valid UPC implementation strategy to define required "predefined" macro identifiers in upc.h, as the whole point of predefined identifiers is they exist prior to lexing any symbols. One might even want to write small prototyping programs that do things like:

1. ifdef UPC
2. include <upc.h>
3. else
4. define shared
5. end

I cannot find a clear definition of "predefined" in C99, but it does declare it undefined if "The name of a predefined macro, or the identifier defined, is the subject of a

1. define or #undef preprocessing directive (6.10.8).", a constraint that is presumably violated if these constants are "predefined" in upc.h.

```

Reported by `danbonachea` on 2012-08-03 15:53:24

[Former user]

``` I concur with the points that Dan makes in Comment 2 above, and support the position that the inclusion of <upc.h> is not required, though of course is necessary if the UPC program makes use of the types and definition in <upc.h>.

Shall we close this as NoChange?

```

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

[Former user]

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

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

[Former user]

Reported by `gary.funck` on 2012-08-19 23:46:24 - Labels added: Consensus-Medium - Labels removed: Consensus-Low

[Former user]

``` Re-classify as "Clarification" and change Summary line to assert that inclusion of <upc.h> is _not_ necessary, to reflect emerging consenus.

```

Reported by `gary.funck` on 2012-08-20 15:32:38 - Labels added: Type-Clarification - Labels removed: Type-Defect

[Former user]

``` Although I changed the Summary line to indicate that <upc.h> might not be necessary, there is a question as to what the specification allows when <upc.h> is not present.

In comment #1, Paul indicated that in the implementation that he used (presumably BUPC+UPCR) that references to MYTHREAD and THREADS "just worked".

Since the specification doesn't currently indicate that <upc.h> must be included in order to introduce the definitions of MYTHREAD and THREADS (for example), then presumably a given UPC implementation is required to either pre-define those definitions or pre-include a header file that provides the definitions. Probably, the pre-include makes the most sense from an implementation stand point because those definitions may vary from one runtime configuration to the next.

```

Reported by `gary.funck` on 2012-08-20 15:40:57

[Former user]

``` I've always thought this was a weird and unnecessary ambiguity in the spec. We should either clearly define what is available outside of upc.h, or we should make it a requirement to include the header. I favor the second option; the first option seems like wasted effort, since the no reasonable application is going to not include upc.h. ```

Reported by `james.dinan` on 2012-08-20 15:52:59

[Former user]

``` I believe the specification is already clear on what falls where - everything in section 7.2 (titled "UPC Utilities <upc.h>") must be defined in upc.h (and may be unavailable without it). Everything else in the spec (notably all of section 6, titled "Language"), including MYTHREAD and THREADS, is required to be available WITHOUT upc.h included.

One could even make a strong argument that implementations which "magically" declare functions like upc_alloc and upc_threadof in a translation unit that does NOT include upc.h are not strictly conforming, but I don't see a motivation to worry about enforcing that.

ISO C does not require any header inclusions to be a conformant program, and by the lack of wording to the contrary, neither does UPC.

I don't believe any spec changes are required here, although we can add a section to the Rationale wiki.

```

Reported by `danbonachea` on 2012-08-20 17:54:05 - Status changed: `NoChange`