Correct UPC_CHAR to be a 'signed' char

[Former user]

Originally reported on Google Code with ID 116

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-08-06 16:35:14

[Former user]

The relevant text from C99 6.2.5, regarding char:

The three types char, signed char, and unsigned char are collectively called
the character types. The implementation shall define char to have the same range,
representation, and behavior as either signed char or unsigned char.35)
35) CHAR_MIN, defined in <limits.h>, will have one of the values 0 or SCHAR_MIN, and
this can be
used to distinguish the two options. Irrespective of the choice made, char is a separate
type from the
other two and is not compatible with either.

So I agree that the definition of UPC_CHAR should be changed to indicate 'signed char',
to ensure the correct behavior on platforms that might define 'plain' char as unsigned.
However, this "sign ambiguity" only applies to "char" and NOT to the other standard
integer types:

6.2.5:
There are five standard signed integer types, designated as signed char, short
int, int, long int, and long long int. (These and other types may be
designated in several additional ways, as described in 6.7.2.)

6.7.2:
Each list of type specifiers shall be one of the following sets (delimited by commas,
when there is
more than one set on a line); the type specifiers may occur in any order, possibly
intermixed with the other declaration specifiers.
— char
— signed char
— unsigned char
— short, signed short, short int, or signed short int
— unsigned short, or unsigned short int
- int, signed, or signed int
— unsigned, or unsigned int
— long, signed long, long int, or signed long int
— unsigned long, or unsigned long int
— long long, signed long long, long long int, or signed long long int
— unsigned long long, or unsigned long long int
Each of the comma-separated sets designates the same type,

So C99 requires that "int" designates the exact same type as "signed int", and similarly
for the other basic integer types that are not char. This means that "signed long int"
is always guaranteed to be a long-winded way to say "long" (pun intended).

Reported by danbonachea on 2013-08-18 00:00:39

[Former user]

Proposed resolution:

--- upc-lib-core.tex    (revision 223)
+++ upc-lib-core.tex    (working copy)
@@ -813,7 +813,7 @@
 \begin{tabular}[b]{ p{30pt} l l }
 & Macro name & Specified type\\
 \cline{2-3}
-\defmacrotab{CHAR}     {char}
+\defmacrotab{CHAR}     {signed char}
 \defmacrotab{UCHAR}    {unsigned char}
 \defmacrotab{SHORT}    {short}
 \defmacrotab{USHORT}   {unsigned short}

No change annotation is required as this section is entirely new in 1.3.

Reported by danbonachea on 2013-08-18 00:06:45

[Former user]

Proposal mailed 8/17/13

Reported by danbonachea on 2013-08-18 00:10:13 - Status changed: PendingApproval

[Former user]

Reported by gary.funck on 2013-09-09 20:35:07

[Former user]

Ratified at the 11/15/13 telecon and committed as SVN r232

Reported by danbonachea on 2013-11-15 19:12:05 - Status changed: Ratified

[Former user]

Adjust summary for clarity

Reported by danbonachea on 2013-11-16 23:34:42

[Former user]

> So C99 requires that "int" designates the exact same type as "signed int", and similarly
for the other basic integer types that are not char. This means that "signed long int"
is always guaranteed to be a long-winded way to say "long" (pun intended).

Yes, but adding 'signed' makes the formatting of the table nicer, as then all the basic
integer types have the type specifier in both cases.  It is also then consistent with
the wording of the reduction suffixes in the table of 7.4.3.1 paragraph 2.

Reported by [e-mail] on 2013-11-18 15:26:59

[Former user]

Sorry to be a stickler for process, but our release is imminent.

This issue was in a PendingApproval state for over three months (during which no comments
were received), and is now officially ratified and committed. The comment period for
this issue is well past, and the issue is now closed. Any further concerns therefore
constitute a new issue, and the deadline for new issues targeted for 1.3 is also well
past.

If you feel this text merits further adjustment, please submit a new issue for 1.4.

Reported by danbonachea on 2013-11-18 18:30:22