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 9
Today's Topics:
C.3.2.1 Array subscripting
C.3.3.2 Address and indirection operators
C.5.1 Storage-class specifiers
C.5.2.1 Structure and union specifiers
C.6.5.1 The while statement & C.6.5.2 The do statement
C.6.6.1 The goto statement
D.12.1 Components of time
D.12.3.1 The asctime function
D.12.3.2 The ctime function
----------------------------------------------------------------------
Date: Thu, 11 Jul 85 00:20:54 edt
From: hcr!lsuc!msb
Subject: C.3.2.1 Array subscripting
To: hcr!cbosgd!std-c
Is it really appropriate for the standard to speak of "usual" things?
C.3.2.1 says that a[b] is "usually" array[integer]. This may be true
as a description of existing programs but it doesn't really mean anything.
Don't the type rules imply that one operand of subscripting has to be
a pointer and the other some kind of integer? Perhaps, instead, this
is worth stating.
------------------------------
Date: Thu, 11 Jul 85 00:20:54 edt
From: hcr!lsuc!msb
Subject: C.3.3.2 Address and indirection operators
To: hcr!cbosgd!std-c
"If an invalid value has been assigned to a pointer, the behavior of the
unary * operator is undefined. Such invalid values include ... a pointer
to void."
This should be rephrased to eliminate the conflict with C.2.2.3, Pointers,
which says: "A pointer to an object of any type may be converted to a
pointer to void ... and back again without change."
------------------------------
Date: Thu, 11 Jul 85 00:20:54 edt
From: hcr!lsuc!msb
Subject: C.5.1 Storage-class specifiers
To: hcr!cbosgd!std-c
This says: "... excess register declarations are treated as auto declarations."
This is less specific than K&R, which states that "only the FIRST few"
register declarations are effective. The sentence should be rephrased
to state that if there are more register declarations than an implementation
allows then the ones that will be accepted will be the first ones.
------------------------------
Date: Thu, 11 Jul 85 00:20:54 edt
From: hcr!lsuc!msb
Subject: C.5.2.1 Structure and union specifiers
To: hcr!cbosgd!std-c
Here again the question of whether "usual" is appropriate arises.
"In the usual case, a struct-declarator is an ordinary declarator for
a member of a structure or union". This seems almost tautological.
------------------------------
Date: Thu, 11 Jul 85 00:20:54 edt
From: hcr!lsuc!msb
Subject: C.6.5.1 The while statement & C.6.5.2 The do statement
To: hcr!cbosgd!std-c
Why use "so long as ... does not equal 0" to define one but "until ...
equals 0" to define the other? Use the same phrase for both. I prefer
the former as being more in the spirit of C. Also, change "The evaluation
takes place" to "the expression is evaluated and tested", or some such.
------------------------------
Date: Thu, 11 Jul 85 00:20:54 edt
From: hcr!lsuc!msb
Subject: C.6.6.1 The goto statement
To: hcr!cbosgd!std-c
No semantics are specified in case the jump is into a compound statement,
unless it is an if, for which they were covered under C.6.4.1, The if statement.
------------------------------
Date: Thu, 11 Jul 85 00:20:54 edt
From: hcr!lsuc!msb
Subject: D.12.1 Components of time
To: hcr!cbosgd!std-c
Two things.
* 1. tm_year should be defined not as "month of the uear" but as "months
since January", just as tm_wday is defined as "days since Sunday".
Months "of the year" would be numbered from 1 to 12, not 0 to 11.
* 2. I believe that "Daylight Savings Time" was never so spelled but was
"Daylight Saving Time", and that in any case this is obsolete and
you should say "Daylight Time".
------------------------------
Date: Thu, 11 Jul 85 00:20:54 edt
From: hcr!lsuc!msb
Subject: D.12.3.1 The asctime function
To: hcr!cbosgd!std-c
Two things.
* 1. Since you are concerned about the use of C in foreign countries where
the character set is not ASCII, you should also consider that these
countries may not use English. I think it should be explicitly stated
that the abbreviations used in the result of asctime ARE ENGLISH ONES.
* 2. It should be stated explicitly that the year portion of the
string is obtained from the tm_year by adding 1900 rather than by
prepending 19. Believe it or not, on DEC's "VAX-11 C" for VMS, it
works the other way ... or at least it does with ctime, they don't
provide asctime.
I suggest, in fact, that the function be defined by saying that if
its arguments are in the proper ranges then it behaves precisely like
the code segment below (where I have omitted a few bits for brevity).
The key part here is the format argument of sprintf.
static const char day_tab[7][4] = { "Sun", "Mon", ..., "Sat" };
static const char mon_tab[12][4] = { "Jan", "Feb", ..., "Dec" };
char *result;
result = ... ;
sprintf (result, "%s%4s%3d %02d:%02d:%02d%5d\n",
day_tab[timeptr->tm_wday], mon_tab[timeptr->tm_mon],
timeptr->tm_mday, ..., timeptr->tm_year + 1900);
return result;
------------------------------
Date: Thu, 11 Jul 85 00:20:54 edt
From: hcr!lsuc!msb
Subject: D.12.3.2 The ctime function
To: hcr!cbosgd!std-c
It should be stated explicitly that the format of the returned string
is the same as that produced by asctime.
------------------------------
End of mod.std.c Digest - Fri, 12 Jul 85 12:04:52 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