osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (07/17/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Tue, 16 Jul 85 Volume 8 : Issue 11
Today's Topics:
C.3.3.3 Unary arithmetic operators - and regrouping
D.1.1 Terms and common definitions
D.2 Diagnostics <assert.h> & D.8.1 Variable argument list access macros
D.3.1.4 The isdigit function
D.5.2.4 The atan2 function
D.6 Non-local jumps
D.7 Signal handling, D.10.4.3 The getenv function & D.10.4.5 The system function
----------------------------------------------------------------------
Date: Sat, 13 Jul 85 00:20:14 edt
From: hcr!lsuc!msb
Subject: C.3.3.3 Unary arithmetic operators - and regrouping
To: hcr!cbosgd!std-c
> * Section C.3, page 26:
>
> To force a particular grouping of operations, either the value
> of an expression to be grouped may be explicitly assigned to
> an object, or grouping parentheses may be preceded by a unary
> plus or minus operator.
>
> and section C.3.3.3, page 31:
>
> . . .Except that it inhibits regrouping, the expression +E
> is equivalent to (0+E).
>
> . . .The expression -E is equivalent to (0-E).
>
> The first quote indicates that with respect to inhibiting regrouping,
> unary plus and unary minus are the same, so the last quotes should
> be either:
>
> . . .The expression +E is equivalent to (0+E).
>
> . . .The expression -E is equivalent to (0-E).
> or:
> . . .Except that it inhibits regrouping, the expression +E
> is equivalent to (0+E).
>
> . . .Except that it inhibits regrouping, the expression -E
> is equivalent to (0-E).
The standard is correct. Regrouping only takes place where the operators
are commutative and associative, which binary - is not. Therefore (0-E)
inhibits regrouping also, and the words "Except that it inhibits regrouping"
are correctly omitted from the statement regarding -. On the other hand,
(0+E) does not inhibit regrouping, so the words are correctly included there.
Mark Brader
------------------------------
Date: Sat, 13 Jul 85 00:20:14 edt
From: hcr!lsuc!msb
Subject: D.1.1 Terms and common definitions
To: hcr!cbosgd!std-c
"NULL ... can be used as an argument to represent the null pointer."
There is no such thing as "the" null pointer; there are only null pointers
of different types, as explained just a few paragraphs above. Delete the
offending clause altogether, or say that (type *) NULL may be used.
* D.1.2 Headers
The note "A header is not necessarily a source file" conflicts with C.8.1,
Source file inclusion, which says nothing about certain names being reserved
and does say that that syntax denotes inclusion of a source file.
------------------------------
Date: Sat, 13 Jul 85 00:20:14 edt
From: hcr!lsuc!msb
Subject: D.2 Diagnostics <assert.h> & D.8.1 Variable argument list access macros
To: hcr!cbosgd!std-c
Why is it mandatory that the specified "functions" be implemented as macros?
------------------------------
Date: Sat, 13 Jul 85 00:20:14 edt
From: hcr!lsuc!msb
Subject: D.3.1.4 The isdigit function
To: hcr!cbosgd!std-c
"... tests for any decimal digit, as defined in C.1.3.2."
Decimal digits are not defined in C.1.3.2, or anywhere else. Hexadecimal
digits, octal digits, nonzero digits, and decimal constants, yes, but not
decimal digits. Therefore, I have no idea what a decimal digit is. :-)
------------------------------
Date: Sat, 13 Jul 85 00:20:14 edt
From: hcr!lsuc!msb
Subject: D.5.2.4 The atan2 function
To: hcr!cbosgd!std-c
"... computes the principal value of the arc tangent of y/x, using the
signs of both arguments to determine the quadrant ..."
The principal value of arc tangent, as noted in D.5.2.3, The atan function,
must be in the 1st or 4th quadrant, and y/x is undefined if x is 0. What
you mean is something like this:
"... computes t such that x = r cos t and y = r sin t for some r. Note that
this is a value of arctan(y/x) if x is not zero. The range of the result is
(-pi, pi]."
Of course, r is in fact sqrt(x*x+y*y).
Perhaps a mathematician can find a terser way of expressing this which
is nevertheless precise.
------------------------------
Date: Sat, 13 Jul 85 00:20:14 edt
From: hcr!lsuc!msb
Subject: D.6 Non-local jumps
To: hcr!cbosgd!std-c
* 1. Due to the special rules for register variables in D.6.2.1, there should
be a forward reference from C.5.1, Storage-class specifiers, to D.6.
* 2. The environmental constraint on where a setjmp call can be located
seems very peculiar on first reading. I think the intention is:
"An implementation may require that the value from a call to setjmp not
appear in any context from which the actual returned value could afterwards
be deduced. That is, it may require that it only appear in the context
of comparison..."
How about expressing it that way?
------------------------------
Date: Sat, 13 Jul 85 00:20:14 edt
From: hcr!lsuc!msb
Subject: D.7 Signal handling, D.10.4.3 The getenv function & D.10.4.5 The system function
To: hcr!cbosgd!std-c
It is really appropriate to require all hosted implementations to provide
these UNIX-like functions? I think this will simply result in ANSI Standard C
being less widely available than it otherwise would be. Yes, I saw the
note in D.7 reducing what an implementation has to do. I still propose making
these functions optional.
------------------------------
End of mod.std.c Digest - Tue, 16 Jul 85 22:55:31 EDT
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.