Add upc_types.h to define common library types

[Former user]

Originally reported on Google Code with ID 10

This ticket is for discussion on the organization of UPC header files.

Current questions:

1. How should the header files for the optional/required libraries be organized?

2. Should upc_flag_t be defined in upc_collectives.h or somewhere else?

3. Should we add a kitchen sink upc_all.h header file?

Reported by james.dinan on 2012-04-24 20:48:29

[Former user]

``` For (2): I think that if something (like upc_flag_t or upc_op_t) are originally created for a particular library, then that definition should stay in upc_mylibrary.h until it is used by two or more required libraries, at which point it is moved into upc.h. That way, we're really only ever changing what goes into upc.h when we're moving libraries into "Required" status, in which case, we're updating the standard anyway.

Relatedly, if we do move to AMOs with an operand function parameter, I think it makes sense to use the upc_op_t type currently defined in the collectives library and move that common definition to upc.h (since one may very well want only collectives or atomics). ```

Reported by `nspark.work` on 2012-04-30 20:58:48

[Former user]

``` Added to 1.3 milestone. ```

Reported by `james.dinan` on 2012-06-15 17:19:09 - Labels added: Milestone-Spec-1.3

[Former user]

``` There hasn't really been any comment on this issue, so unless there are any objections, I think it makes sense to move upc_op_t from the UPC Collectives library and header into the UPC Core library and upc.h.

By doing this, upc_op_t will be available to both the UPC Collectives and UPC AMO libraries by default and including upc_collectives.h won't be required for the UPC AMOs.

Also, the spec text will need to be changed to reflect whether a particular library that uses upc_op_t uses ALL of the provided enums (like Collectives) or just SOME of them (like Atomics). We'll work that with the AMO library. ```

Reported by `nspark.work` on 2012-06-28 20:07:47

[Former user]

``` Nick wrote: "There hasn't really been any comment on this issue, so unless there are any objections, I think it makes sense to move upc_op_t from the UPC Collectives library and header into the UPC Core library and upc.h."

We had a separate discussion (for which I don't think an issue has been logged) regarding upc_flag_t. As I unserstand it, it was determined that upc_flag_t must be defined in upc.h, so that various libraries can refer to a common definition for the sync. flags. I no longer recall the history of how upc_flag_t came into being, nor the specific reasons for it being required to be defined in upc.h. That said, it seems that upc_op_t may have some thngs in common with upc_flag_t and perhaps both of them should follow the same convention regarding where/how they are defined.

Worth noting, in the 1.2 specification whenever upc_collective.h is #include-d in order to introduce a function prototype, upc.h is always included before it. This seems like a good convention for all non-core libraries to follow.

In the 1.2 UPC specification that upc_flag_t #define's (UPC_IN_NOSYNC, UPC_IN_MYSYNC, UPC_IN_ALLSYNC, UPC_OUT_NOSYNC, UPC_OUT_MYSYNC, and UPC_OUT_ALLSYNC) are described in section 7.2.6 ("Memory Semantics of Library Functions").

In the current 1.3 draft version of the specification, we have retained section 7.2.6 in the main specification document, but now there are no uses of those definitions in the main document, because the UPC collectives library was moved to a seeparte required library document. In fact, we still need to work out how to resolve those cross document references.

I do not believe that as new libraries come along that there will be a smooth path for their migration into the core library, because movement into the core library, as mentioned above requires an update to the UPC specification.

Further, it could be argued (I won't, because I don't recommend this approach) the <upc_collectives.h> header could be dropped, since only <upc.h> is (currently) required to access the functions supplied by the core library.

The conclusion that I reach based on the above is that there may be some common typedef's and common #defines that are useful to other libraries (core, required, and optional) but that by using these common definitions it does not elevete the status of the lbrary itself to that of the core library.

With the specification split, we arrive at an interesting point, vis-a-vis, upc_flag_t for example. Based on the reasonging above, we may wish to retain upc_flag_t in the main body of the specification, btu beyond its defintion there will be no references upc_flag_t. Those uses are in the required library (the UPC collectives library) and in the optional library (UPC I/O) and potentially other libraries.

Given upc_op_t's potential role as a commonly used definition perhaps it should be handled in a similar manner as upc_flag_t?

A brief editioril note: I think that the collectives libraries would have been easier to work with if they did supply the operation as a upc_op_t parameter value, but rather that there should be a unique prototype for each data type that is operated on. This would cause the introduction of many new prototypes, but type safety could be preserved and it is one less thing for the programmer to worry about. I'm aware the MPI use the approach of passing in a value that indicates the date type, and from what I recall MPI can even perform dynmaic data type conversions when source and destination types doen't match. This level of flexibility (and complexity) would not be my preference.

I don't particularly like over-brudening the main UPC language specification with type definitions and #define's that are used by separate libraries, but perhaps for upc_flag_t and upc_op_t it is necessary.

```

Reported by `gary.funck` on 2012-06-28 22:18:53

[Former user]

``` Since this issue covers various uses of UPC-related headers, I will post the following question here, and based upon the discusssion and replies will create a new issue ticket.

Wehn we first started working with UPC, I recall that being told 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?

```

Reported by `gary.funck` on 2012-06-28 22:29:36

[Former user]

``` A follow up to Nick's proposal in comment #3: I support the idea of moving 'upc_op_t' into the main body. We will need to add a new section similar to section 7.2.6 ("Memory Semantics of Library Functions").

That said -- below I offer an alternative, which has some advantages in terms of managing separate language and library specifications.

A few corrections to my comment #4 ...

The following remarks were tangential to the main discussion:

"I do not believe that as new libraries come along that there will be a smooth path for their migration into the core library, because movement into the core library, as mentioned above requires an update to the UPC specification.

Further, it could be argued (I won't, because I don't recommend this approach) the <upc_collectives.h> header could be dropped, since only <upc.h> is (currently) required to access the functions supplied by the core library."

Above, I was anticipating what might occur, if for example, the UPC collectives library were moved from 'required' to 'core'. I was also (not clearly) trying to make the point that the decision to include common helper typedef's and #define's into the main body of the spec., did not imply inclusion of the libraries that referenced them.

An alternative --------------

Simply arrange by convention that types/defines like those associated with upc_flag_t are agreed upon by convention, and their description is replicated in each library that needs them. Implementers can ensure uniqueness across libraries with the usual

1. define and #include tricks. Or, we can invent new header files: upc_flags.h and upc_ops.h, replicate their descriptions where needed and indicate that the library header file will automatically include them. This alleviates the need to update the main body of the specification to include common types and defines as they come along, and eliminates cross-references between the library specifications and the main body of the UPC specification. I prefer this approach because it allows libraries to evolve independently of the main specification and further makes it possible for each library document to be stand-alone.

Re: this sentence - "A brief editioril note: I think that the collectives libraries would have been easier to work with if they did *not* supply the operation as a upc_op_t parameter value, but rather that there should be a unique prototype for each data type that is operated on."

Above, I have added the key missing word: *not*. The omission was likely obvious, but for clarity, I am re-stating it.

```

Reported by `gary.funck` on 2012-06-29 17:56:36

[Former user]

``` How about a upc_types.h that we can put all UPC types (wherever they come from) in, that is automatically included by upc.h. In the core spec, we define what types *MUST* be included there. We also say in the core spec that any further UPC types provided by the implementation will also be found there, but don't define what those types are. In the various library specs, the new types are listed, and implementations that implement optional libraries are required to add those types to upc_types.h. ```

Reported by `[e-mail]` on 2012-06-29 18:02:17

[Former user]

``` This may be more appropriate for the AMO thread, but since it's a reply to something said here, I'll put it here.

Gary said:

A brief editioril note: I think that the collectives libraries would have been easier to work with if they did *not* supply the operation as a upc_op_t parameter value, but rather that there should be a unique prototype for each data type that

is operated on.

I'm not quite sure I see how upc_op_t as a parameter affects the per-datatype prototypes. The Collectives library specifies separate function prototypes for the 22 datatypes of upc_all_reduce *and* has the operation as a upc_op_t parameter.

I've based my initial spec text for the AMO library on this upc_all_reduce definition, in particular for consistency reasons. If there are objections to this prototype style, please speak up. (IIRC, Cray like this approach, as it reduced some of the interface bloat of one function per datatype*operation.) ```

Reported by `nspark.work` on 2012-07-02 14:07:17

[Former user]

``` Nick, thanks for the follow-up. Although the prototypes are differentiated by type, there arguments are still (shared void *). Here is the general prototype:

void upc_all_reduceT(shared void * restrict dst, shared const void * restrict src, upc_op_t op, size_t nelems, size_t blk size, TYPE(*func)(TYPE, TYPE), upc_flag_t flags);

and a specific instance:

extern void upc_all_reduceI (shared void *dst, shared const void *src, upc_op_t op, size_t nelems, size_t blk_size, signed int (*func) (signed int, signed int), upc_flag_t sync_mode);

It seems that the main purpose of TYPE is to define the type of the function that is the target of the 'func' pointer. However, the 'func' pointer is only needed when the operation type is UPC_FUNC. Thus, for type safety, I would recommend that the 'src' and 'dst' pointers refer to their appropriate target types. Further, I'd recommend that there are separate prototypes for each current value of upc_op_t. If that were to occur, then two arguments can be dropped for the typical case: 'op' and 'func'.

In the (1.4) proposal that I haven't yet written, if block size were provided in a VLA-like fashion, the prototype above might appear as:

extern void upc_all_reduce_add_I (shared [blksize] int dst[nelems], shared [blksize] const int src[nelems], size_t nelems, size_t blk_size, upc_flag_t sync_mode);

I'd also like to find a way to remove 'sync_mode', since it is almost always the same and likely generally not well-understood.

If UPC were extended to become UPC++, or simply the "C" subset of C++, then the values of blk_size and sync_mode could be defaulted and the prototypes overloaded, along these lines:

extern void upc_all_reduce_add (shared [blksize] int dst[nelems], shared [blksize] const int src[nelems], size_t nelems, size_t blk_size = 1, upc_flag_t sync_mode = UPC_IN_NOSYNC|UPC_OUT_NOSYNC);

If I got that right, the call could be reduced to three parameters, dst, src, and nelems.

... that *is* a digression, however.

```

Reported by `gary.funck` on 2012-07-02 14:55:57

[Former user]

``` Apologies if this is obvious, but why are we standardizing new types for things that are already covered well by the base language? Ops and flags are integer constants, why should we add special types for them? ```

Reported by `james.dinan` on 2012-07-02 15:46:48

[Former user]

``` Jim wrote: "why are we standardizing new types for things that are already covered well by the base language? Ops and flags are integer constants, why should we add special types for them?"

I was not proposing additional, special types. I was advocating changing things like (shared void *dst) to (shared int *src), but now that I reflect on that ... the ability to make that change may require the proposed language extension (for version 1.4) that allows blocking factors to be specified in VLA-like fashion. Otherwise, (shared void *) is the only sufficiently general type to encompass all block sizes.

All that discussion in comment 9 was a digression, however. The main point of this issue is to address how header files are managed. The particular thread in question is: how to manage/define upc_flag_t and upc_op_t.

Note: this issue should really be separated into several separate issues.

```

Reported by `gary.funck` on 2012-07-02 16:14:59

[Former user]

``` Jim wrote:

Apologies if this is obvious, but why are we standardizing new types for things that

are already covered well by the base language? Ops and flags are integer constants,

why should we add special types for them?

I think the motivation for upc_op_t and upc_flag_t, which are fundamentally integer constants, is to have a convenient name for the defined values, which is usually a typedef'd enumeration. ```

Reported by `nspark.work` on 2012-07-02 16:19:40

[Former user]

``` Re: Comment #12

Flags, in particular, are defined such that the values can be combined with OR and later separated with AND. As an example, the Unix file interface uses an integer argument for such flags.

I guess the definition of an op type seems ok, particularly if we ever want to support user defined operations. ```

Reported by `james.dinan` on 2012-07-02 17:28:38

[Former user]

``` Nick wrote:

Jim wrote:

Apologies if this is obvious, but why are we standardizing new types for things

that

are already covered well by the base language? Ops and flags are integer constants,

why should we add special types for them?

I think the motivation for upc_op_t and upc_flag_t, which are fundamentally integer

constants, is to have a

convenient name for the defined values, which is usually a typedef'd enumeration.

In addition to having a convenient name, implementation via an enum allows some compilers to report cases in which one is passing a value that is not defined as part of that enum type, as well as reporting "suspicious activity" such as arithmetic with an enumerated type (what does UPC_OP_ADD * UPC_OP_XOR mean?). ```

Reported by `[e-mail]` on 2012-07-02 17:30:21

[Former user]

``` The discussion relating to the first sub-issue above: 1. How should the header files for the optional/required libraries be organized? has been moved to issue #66.

The subject of this issue has been changed to "Should upc_flag_t be defined in upc_collectives.h or somewhere else?" and its Type has been changed to "Clarification".

```

Reported by `gary.funck` on 2012-07-17 19:49:12 - Labels added: Type-Clarification - Labels removed: Type-Defect

[Former user]

``` sub-item 3. in the original ticket description has been split out as a separate issue

1. 67 "Add a kitchen sink upc_all.h header file?".

```

Reported by `gary.funck` on 2012-07-17 19:56:38

[Former user]

``` Currently, upc_flag_t is defined in 7.2.6 ('Memory Semantics of Library Functions') under the section that I think we now consider representing "core" library functions. I've currently modified (not yet committed) the LaTeX such that upc_flag_t and upc_op_t are defined in 7.2.6 (as 'Library Support Types'), but it sounds like (via the comments in Issue #10) these should be moved outside specific reference to upc.h to a 7.3 section on UPC Types using upc_types.h.

Does this sound like a reasonable organization?

Should the definition of upc_lock_t be moved from 7.2.4.1 to the new 7.3? ```

Reported by `nspark.work` on 2012-07-24 15:14:03

[Former user]

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

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

[Former user]

``` I haven't had an opportunity to read all of the detailed discussion in this and related threads, so I apologize if this has already been discussed elsewhere. I think I have a pretty simple opinion on this that differs from the discussion thus far:

I think we should put everything in one header file.

AFAICT, the multiple headers approach trades a small compilation time savings for a significant productivity loss for users and for us, the authors of the spec. I'm also not convinced that it won't present backward compatibility problems, e.g. when we would move proposed libraries into accepted library headers. ```

Reported by `james.dinan` on 2012-08-20 02:40:14

[Former user]

```

AFAICT, the multiple headers approach trades a small compilation time savings for

a

significant productivity loss for users and for us, the authors of the spec.

One of the primary benefits of separate headers is to allow separate implementation of libraries, ie third-party implementations which aren't built-in to the UPC compiler, or possibly even override the built-in version via -I/-L precedence on the compile line. This greatly assists in prototyping (eg reference implementations of proposed libraries) and allows the existence of library implementation efforts separate from compiler projects.

The current discussion is working under the assumption that everyone (compiler writers and library writers) can agree upon a single definition for the widely-used upc_flag_t and upc_op_t, so we can place those in a common location to be used by all headers, regardless of author.

So far the options seem to be:

1. define them directly in <upc.h>. This means the compiler provides them and they are universally available. It also means third party library implementations can never modify them, but perhaps that's a Good Thing to ensure binary compatibility of the values between separately-authored library objects. 2. define each type in a small, separate header, which is included by upc.h. This option still "looks" the same to the user, but allows third-party libraries to override the version provided by the compiler.

```

Reported by `danbonachea` on 2012-08-20 03:10:00

[Former user]

``` I think I'm leaning towards option 2 from comment #20, because it allows library implementation code written in pure C99 to include the appropriate value definitions for this UPC compiler implementation. If they were embedded directly in upc.h they would not be directly include-able by library objects compiled by the plain C compiler, so third party implementations may need additional "magic" configure logic to parse them out. ```

Reported by `danbonachea` on 2012-08-20 03:24:18

[Former user]

``` Re: #20

I don't think that we should standardize on this build-it-yourself model for assembling a UPC implementation at compile time. If a UPC implementation is compatible with a third-party implementation of some functionality, this should be incorporated by the user when they build the UPC compiler, or included as a special command-line option to the UPC compiler. Otherwise, we are taking a portability/ease-of-use risk. ```

Reported by `james.dinan` on 2012-08-20 12:33:37

[Former user]

``` "I don't think that we should standardize on this build-it-yourself model for assembling a UPC implementation at compile time. "

I strongly disagree. Reference implementations and independent library implementation have already proven themselves as strong prototyping tools for emerging UPC libraries. Reference implementation is even one of the standardization paths listed in Appendix A for new library approval. There are some libraries (notably UPC-IO) that make sense to be implemented and optimized by a group separate from the UPC implementation (GWU UPC-IO and MPI's ROMIO was a good example of this model). It's not reasonable or even feasible to expect UPC implementations to somehow bundle every possible reference library implementation out there - the whole point is that early users can include and use these separately without help from the implementation. The ability to do this is fundamental to ISO C's library feature (as different from the standard libraries).

We should not specify anything that "breaks" the ability to create reference implementations of new libraries, which is already supported by 1.2. I agree it's not the primary concern moving forward on the issue of placing upc_flag_t and friends, but all else being equal it's a nice feature to provide. It's also worth noting that C99 separates headers with system-dependent definitions like errno.h, inttypes.h, signal.h, into tiny, separate headers, and this is important for portable C compilers to integrate with the POSIX functionality of their target platforms. ISO C has a long history of creating new, small headers to encapsulate each functionally-independent feature or group of factorized definitions. If we follow that model with upc_flag_t and upc_op_t, we can still specify that upc.h includes those headers so it works the same for the user.

```

Reported by `danbonachea` on 2012-08-20 18:22:13

[Former user]

``` So what happens when you have multiple libraries that make use of these types, but come from different sources? Let's say Library A and Library B use upc_flag_t. An implementation provides Library A, but not Library B. A user wishes to use both, so goes and grabs a reference implementation of Library B. But it defines upc_flag_t differently, so the user cannot use both Library A and Library B in the same program. ```

Reported by `[e-mail]` on 2012-08-20 18:51:27

[Former user]

``` "But it defines upc_flag_t differently, so the user cannot use both Library A and Library B in the same program."

Neither library should define upc_flag_t - that's the point. We've agreed upc_flag_t is a common type that should be provided by the implementation, now we're just arguing about where to place it. If we go with my option 2, the implementation provides upc_flag_t in a small header like <upc_types.h>. Both Library A and Library B include that header and use the values defined therein. Because upc_types.h just contains pure C definitions, Library C might even use a pure C implementation that includes <upc_types.h> directly.

```

Reported by `danbonachea` on 2012-08-20 18:55:23

[Former user]

``` "Both Library A and Library B include that header and use the values defined therein."

And how do we coordinate extensions? For instance, the collectives 2.0 proposal includes a new flag for upc_flag_t. If a UPC implementation doesn't support the new extension, the reference implementation would need to define the new value *somehow* without clobbering existing values, which may include other extensions. ```

Reported by `[e-mail]` on 2012-08-20 19:05:53

[Former user]

``` Dan, thanks for taking the time to explain the usage model. I do agree that this mode of substitution is useful for implementers and research users, but it will be tricky for application users. One concern is that the standard will essentially define the units of functionality that folks can override. It doesn't seem like we would have a clean mechanism for overriding a subset of functionality, like one might do with library interposition and weak symbols. ```

Reported by `james.dinan` on 2012-08-20 20:30:36

[Former user]

``` "It doesn't seem like we would have a clean mechanism for overriding a subset of functionality, like one might do with library interposition and weak symbols."

Agreed - we probably should not specify that these types can be completely overridden, although some implementations might choose to provide that as a feature. However that should not be necessary to support reference implementations.

"And how do we coordinate extensions? For instance, the collectives 2.0 proposal includes a new flag for upc_flag_t... define the new value *somehow* without clobbering existing values, which may include other extensions.

This is potentially a problem, but it is mostly orthogonal to the issue of where an implementation defines these types to support its required standard libraries. An extension that needs to insert a new unique value macro would probably need to parse the UPC compiler's <upc_types.h> at library build time (using a tool like autoconf), and choose an appropriate value for its new macro definition. Providing <upc_types.h> as an isolated pure-C header that defines the macros mandated by the core library spec will make that easier.

Note it doesn't actually matter if two different extension libraries choose the same value for a new, library-extension upc_flag_t macro value. Each new flag is only meaningful to the given library, and the programmer constructs his upc_flag_t value to call a specific extension library. So if Library A defines UPC_LIBA_SPECIALFLAG=128 which its functions recognize, and Library B defines UPC_LIBB_SPECIALFLAG=128 for its functions, that's not a problem because the two flags are never combined into the same expression at runtime anyhow. All that matters is they don't conflict with the implementation values required by the core spec (UPC_IN_ALLSYNC, etc) which are valid arguments to all libraries.

```

Reported by `danbonachea` on 2012-08-20 21:07:12

[Former user]

Reported by `danbonachea` on 2012-09-28 23:42:34 - Blocking: #7

[Former user]

Reported by `gary.funck` on 2012-09-28 23:48:39

[Former user]

``` Mass change "Accepted" issues which haven't seen activity for over a month back to "New", for telecon discussion. ```

Reported by `danbonachea` on 2012-10-04 11:36:12 - Status changed: `New`

[Former user]

``` In the 10/5 telecon it was agreed I would draw up a concrete proposal for a upc_types.h, so we have a solid basis for further discussion.

The basic idea is a header upc_types.h, defined in the core library document (language spec section 7), that will be automatically included by upc.h and the headers for libraries that use it (so a user never needs to directly include it).

It will define these types: upc_flag_t upc_op_t upc_type_t and corresponding value macros that are sufficiently general to be used by multiple libraries. Individual libraries are permitted to extend with additional library-specific value macros. The entire header will be suitable for processing with a vanilla C compiler.

```

Reported by `danbonachea` on 2012-10-07 19:49:53 - Status changed: `Accepted` - Labels added: Priority-Critical, Consensus-Medium - Labels removed: Priority-Medium, Consensus-Low

[Former user]

``` Official proposal mailed 10/8/2012

Attached find PDFs reflecting the proposed changes for issue10, now committed to the issue10 branch.

Summary of changes:

• New section 7.3 in the language document defines the header, and also contains the old section defining upc_flag_t semantics.
• upc_types.h is automatically included by upc.h, and is also suitable for processing with a vanilla C compiler.
• upc_types.h defines types: upc_flag_t, upc_op_t, upc_type_t and corresponding value macros that are sufficiently general to be used by multiple libraries.
• Individual libraries are permitted to extend with additional library-specific value macros.
• upc_collective.h now includes upc_types.h and defines additional upc_op_t values: UPC_FUNC and UPC_COMMFUNC
• upc_io.h now includes upc_types.h, and broken links to upc_flag_t in the UPC-IO spec are now fixed
• The AMO header will need to include upc_types.h and defines additional upc_op_t values:

UPC_GET, UPC_SET, UPC_CSWAP and UPC_NOT

• Fix a few cosmetic glitches in UPC collectives section

```

Reported by `danbonachea` on 2012-10-08 14:10:42 - Status changed: `PendingApproval`

<hr>

• *Attachment: [upc-lang-spec-draft2.1-issue10.pdf](https://storage.googleapis.com/google-code-attachments/upc-specification/issue-10/comment-33/upc-lang-spec-draft2.1-issue10.pdf)*
• *Attachment: [upc-lib-required-spec-draft2.1-issue10.pdf](https://storage.googleapis.com/google-code-attachments/upc-specification/issue-10/comment-33/upc-lib-required-spec-draft2.1-issue10.pdf)*
• *Attachment: [upc-lib-optional-spec-draft2.1-issue10.pdf](https://storage.googleapis.com/google-code-attachments/upc-specification/issue-10/comment-33/upc-lib-optional-spec-draft2.1-issue10.pdf)*

[Former user]

Attached is a reference implementation of the proposed header (which I've made public
domain and free-to-use for any implementation) and a corresponding test code.

Reported by danbonachea on 2012-10-09 19:47:10

<hr> * Attachment: upc_types-1.0.tar.gz

[Former user]

George's comment on the call convinced me (after further thought) that upc_types.h should
reserve a few extra bits in upc_op_t for future expansion, and also that we need to
specify a maximal upc_type_t value to allow library-specific augmentations.

--- upc-lib-core.tex    (revision 153)
+++ upc-lib-core.tex    (working copy)
@@ -644,7 +644,7 @@
 which are suitable for use in {\tt \#if} preprocessing directives.
 Each macro value designates the specified operation.
 The expressions are defined such that bitwise or ({\tt |}) of all combinations
-of the macros result in distinct positive values less than 512.
+of the macros result in distinct positive values less than 65536.
 \begin{tabular}{ p{30pt} l l }
 & Macro name & Specified operation\\
 \cline{2-3}
@@ -674,7 +674,7 @@

 \np The \header header defines the following macros,
 which expand to integer constant expressions with type {\tt upc\_type\_t},
-distinct positive values, and which are suitable for use 
+distinct positive values less than 65536, and which are suitable for use 
 in {\tt \#if} preprocessing directives.
 Each macro value designates the specified type.

Reported by danbonachea on 2012-10-09 21:30:01

[Former user]

In 7.3 p3, why does "All of the functions are collective." have a footnote to "DB: Issue
#10: Add upc_types.h to define common library types"?

Reported by nspark.work on 2012-10-11 12:41:00

[Former user]

"In 7.3 p3, why does "All of the functions are collective." have a footnote to "DB:
Issue #10: Add upc_types.h to define common library types"?"

Those non-numeric footnotes are the changes annotation package (provides a visual "diff"
in Latex), and won't appear in the final version. The changes package does not support
directly annotating a footnote, which is why it looks a bit awkward in that particular
case.

Reported by danbonachea on 2012-10-11 17:16:56

[Former user]

Ratified at the 11/9/12 telecon.

Reported by danbonachea on 2012-11-09 22:52:20 - Status changed: Ratified

[Former user]

Is there a reason for the requirement that the predefined values of upc_type_t be "distinct
positive values less than 65536"?  It seems that the exact-width types should be mapped
onto the appropriate integer type for the platform.  For instance, on a system using
the amd64 abi, we'd have

UPC_INT8   == UPC_CHAR
UPC_UINT8  == UPC_UCHAR
UPC_INT16  == UPC_SHORT
UPC_UINT16 == UPC_USHORT
UPC_INT32  == UPC_INT
UPC_UINT32 == UPC_UINT
UPC_INT64  == UPC_LONG
UPC_UINT64 == UPC_ULONG
etc...

Do we envision a use-case where these types would actually need to be treated differently
within a single implementation?  If not, why bother requiring them to be unique?  If
so, why only these and not the other standard integer types?

On a related note, the table in 7.3.2 paragraph 2 giving the types corresponding to
the macros needs to be updated to explicitly used 'signed char' for 'UPC_CHAR' (and
probably add signed to the other signed integer types as well), as 'char' alone is
not guaranteed to be signed.  Note that the table in 7.4.3.1 paragraph 2 explicitly
uses 'signed'.

Reported by [e-mail] on 2013-06-03 21:20:19

[Former user]

Moving Steve's comment from this ratified issue to new issue 115

Reported by danbonachea on 2013-08-03 04:50:56