[mod.std.c] mod.std.c Digest V8#8

osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (07/12/85)

From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>


mod.std.c Digest            Fri, 12 Jul 85       Volume 8 : Issue   8 

Today's Topics:
                   C.1.2.2 Linkages of Identifiers
                 C.1.2.4 Storage durations of objects
                            C.1.2.5 Types
         C.1.3.3 Character constants & C.1.4 String literals
                 C.2.1.2 Signed and unsigned integers
----------------------------------------------------------------------

Date: Thu, 11 Jul 85 00:20:26 edt
From: hcr!lsuc!msb
Subject: C.1.2.2 Linkages of Identifiers
To: hcr!cbosgd!std-c

I found it quite hard to understand what this section was trying to say,
even though I thought I already knew, until I realized that "instance
of a particular identifier" refers to instances governed by different
declarations.  Without that understanding, it seems to say that a = f(a);
refers to two different variables called a, if a is an auto.

I suggest substituting something like "instance of a declaration of
a particular identifier" for "instance of an identifier".

------------------------------

Date: Thu, 11 Jul 85 00:20:26 edt
From: hcr!lsuc!msb
Subject: C.1.2.4 Storage durations of objects
To: hcr!cbosgd!std-c

"An object that has static storage duration exists and retains its value
(unless explicitly modified) throughout the execution of the entire program."

This needs to be rephrased to allow static volatile objects.

------------------------------

Date: Thu, 11 Jul 85 00:20:26 edt
From: hcr!lsuc!msb
Subject: C.1.2.5 Types
To: hcr!cbosgd!std-c

Four things.
* 1. It seems to me that the void type is semantically an empty
enumeration, yet enumerations are classified as derived types and
void isn't.  I think they should both be called derived types or both not.
I favor not, because the other derived types are defined in terms of
the basic types (or other derived types), and enumerations are not.

* 2. It is stated explicitly that "the set of values of an int includes all
possible values of a short int; the set of values of a long int includes all
possible values of an int."  But nothing is said about the fourth signed integer
type, signed char.

Now, C.3.3.4, The sizeof operator, says that sizeof(char) is 1;
C.1.2.5 says that sizeof(signed char) == sizeof(char); and A.6, Definitions,
says that all objects are made up of bytes.  Does this not imply that
"the set of values of a short int includes all possible values of a
signed char"?  Then I suggest that the standard should come right out
and say so explicitly, in parallel with the clauses about int, short
int, and long int.

If I'm wrong, there must be something subtle here, and in that case
I think it should be explained in a note.

* 3. C.1.2.5 guarantees that sizeof(char), sizeof(signed char), and
sizeof(unsigned char) are all equal, and that if things that aren't
ordinary characters are stored in a char, "the values are treated as
either signed or non-negative integers".  It appears to me that this
implies that a char is guaranteed to be equivalent to one of signed
char and unsigned char, rather than different from either.

I suggest that, for clarity's sake, this should be stated explicitly
either in a note or in the text proper.  Forward references could be
avoided by resequencing the paragraphs on chars and integers.

Again, if I'm wrong, I think the reason I'm wrong should be worth an
explanatory note.

* 4. "For signed char and each type of int, there is a corresponding
unsigned type (declared with the keyword unsigned) that occupies the
same amount of storage."  This sounds as if one is supposed to declare
"unsigned signed char".  I suggest: "There are four types of unsigned
integers, declared unsigned char, unsigned short int, unsigned int, and
unsigned long int, and each occupies the same amount of storage as the
corresponding signed type."

------------------------------

Date: Thu, 11 Jul 85 00:20:26 edt
From: hcr!lsuc!msb
Subject: C.1.3.3 Character constants & C.1.4 String literals
To: hcr!cbosgd!std-c

One section tells how to represent ' and " and ?, while the other tells
only how to represent ' and ", in the textual portions of the description.

------------------------------

Date: Thu, 11 Jul 85 00:20:26 edt
From: hcr!lsuc!msb
Subject: C.2.1.2 Signed and unsigned integers
To: hcr!cbosgd!std-c

"When a signed integer is ASSIGNED TO, OR USED AS ONE OF THE OPERANDS OF
A BINARY OPERATOR THE OTHER OPERAND OF WHICH IS, an unsigned integer of
equal or greater length, the signed integer IS FIRST CONVERTED to a signed
integer of the same length as the unsigned integer.  If the value of the
signed integer is negative, THE CONVERSION involves adding to it the
largest number that can be represented in the unsigned integer type plus 1."

There are two things wrong here.
* 1. Arithmetic conversions can happen in at least two other circumstances
besides those listed in the first emphasized phrase (casts and calls to
functions whose parameter types were specified).  The same conversion rules
are followed in each case.  In any case the circumstances where conversion
will occur are described later.  The first emphasized phrase should be
replaced by "converted to", as in the preceding paragraph.

* 2. Because of the choice of words, the third emphasized phrase seems
to refer back to the second one rather than to the first, which makes the
definition confusing.  This again can be improved by shortening.  I suggest
that the paragraph should read:

"When a signed integer IS CONVERTED to an unsigned integer of
equal or greater length, the signed integer is first converted to a signed
integer of the same length as the unsigned integer.  THEN, if ITS value
is negative, the largest number that can be represented in the unsigned
integer type, plus 1, IS ADDED TO IT."

Also, perhaps all the definitions of conversions would read more clearly
if the word "value" was added before "is converted to", in the sentence
"When a (type1) is converted to a (type2)".

------------------------------

End of mod.std.c Digest - Fri, 12 Jul 85 11:53:25 EDT
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
It is preferred to reply to the author of the articles here,
with copy to the moderator: cbosgd!std-c...
		 { decvax | ihnp4 | watmath | ... } !utzoo!lsuc!msb
		    also via { hplabs | amd | ... } !pesnta!lsuc!msb
Mark Brader		and		   uw-beaver!utcsri!lsuc!msb