osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (05/15/86)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Thu, 15 May 86 Volume 16 : Issue 12
Today's Topics:
MORE C standard differences Apr85-Feb86, part 2 of 9
----------------------------------------------------------------------
Date:
From: ihnp4!utzoo!lsuc!msb
Subject: MORE C standard differences Apr85-Feb86, part 2 of 9
To: utzoo!ihnp4!hou2d!osd
# D.3.1 Character testing functions
* In an implementation that uses the {--> seven-bit} ASCII charac-
ter set, the printing characters are those whose values lie
* between 0x20 (space) and {0xFE --> 0x7E} (tilde); the control
* characters are those whose values lie between 0 (NUL) and {0x17
* --> 0x1F} (US), and the character {0xFF --> 0x7F} (DEL).
# D.3.1.1 The isalnum function
* The isalnum function tests for any {letter or digit --> character
for which isalpha or isdigit is true}.
# D.3.1.2 The isalpha function
* The isalpha function tests for any {letter --> character for
which isupper or islower is true, or any of an implementation-
defined set of characters for which none of iscntrl, isdigit,
ispunct, or isspace is true}.
# D.3.1.6 The islower function
* The islower function tests for any lower-case letter {--> as de-
fined in #B.2.1, or any of an implementation-defined set of char-
acters for which none of iscntrl, isdigit, ispunct, or isspace is
true}.
Remark: Likewise for isupper (#D.3.1.10).
# D.3.1.8 The ispunct function
The ispunct function tests for any printing character except
* space (' ') {, a digit, or a letter --> or a character for which
isalnum is true}.
# D.3.2.1 The tolower function
If the argument is an upper-case letter, the tolower function re-
* turns the corresponding lower-case letter {-->, if any}; ...
Remark: Likewise for toupper (#D.3.2.2).
# D.4 LIMITS {--> <float.h> and} <limits.h>
* The headers {--> <float.h> and} <limits.h> define several macros
* that ... were listed in {#B.2.4.1 --> #B.2.4.2}.
# D.5 MATHEMATICS <math.h>
...
HUGE_VAL
* which expands to a positive double expression {-->, not neces-
sarily representable as a float}.
# D.5.1 Treatment of error conditions
* On a domain error, the {int --> integer expression} errno {is set
to --> acquires the value of} the macro EDOM, and the function
* returns {the value indicated --> an implementation-defined
value}.
Remark: The sentences that formerly gave the value that each
function returned on a domain error are deleted, but I will not
list them individually.
# D.5.2.3 The atan function
* The atan function returns the arc tangent in the range {[-pi/2,
pi/2] --> (-pi/2, pi/2)}.
Remark: In other words, the endpoints of the range are now impos-
sible.
# D.5.4.4 The log function
* A domain error occurs if the argument is {zero or -->} negative.
* {--> A range error occurs if the argument is zero.}
Remark: Likewise for log10 (#D.5.4.5).
# D.5.6 {--> Nearest integer,} absolute value, {nearest integer,
-->} and {modulo --> remainder} functions
Remark: The abs function is moved from #D.5.6.1 to #D.10.6.1.
See below. The other functions' sections are renumbered accord-
ingly.
# D.6.1.1 The setjmp function
* {--> If the return is from a direct invocation,} the setjmp func-
* tion returns the value zero. {--> If the return is from a call
to the longjmp function, the setjmp function returns a non-zero
value.}
# D.6.2.1 The longjmp function
All accessible objects have values as of the time longjmp was
* called, except that the values of objects of {storage class re-
gister --> automatic storage class that do not have volatile
type} and have been changed between the setjmp and longjmp calls
are indeterminate.
# D.7 SIGNAL HANDLING <signal.h>
* Additional signals, {--> with macro definitions beginning with
the letters SIG followed by an upper-case letter and} with signal
numbers distinct from those listed, may also be specified by an
implementation.
# D.7 SIGNAL HANDLING <signal.h>
N--> The names of the signal numbers reflect the following terms
N--> (respectively): abort, floating-point exception, illegal instruc-
N--> tion, interrupt, segment violation, and termination.
Remark: Respectively, that's SIGABRT, SIGFPE, SIGILL, SIGINT,
SIGSEGV, and SIGTERM.
# D.7.1.1 The signal function
N--> As the functions in the standard library are not guaranteed to be
N--> reentrant and may modify objects with static storage duration,
N--> they may not be used reliably in a signal handler that returns.
# D.8 VARIABLE ARGUMENTS <stdarg.h>
* The header <stdarg.h> declares a type {--> and a function} and
* {--> defines} {several --> two} macros for advancing through a
list of arguments ...
# D.8 VARIABLE ARGUMENTS <stdarg.h>
A function may be called with a variable number of arguments of
* varying types. As described in {#C.7.1.1 --> #C.7.1}, its param-
eter list contains one or more parameters.
# D.8.1 Variable argument list access macros {--> and function}
* The {capabilities --> va_start and va_arg macros} described in
this section shall be implemented as macros, not as real func-
tions.
Remark: Va_end is now allowed to be a function, and this change
applies throughout this section.
# D.8.1.2 The va_arg macro
* {--> If} the specified type {must agree --> disagrees} with the
type of the actual next argument (as promoted ... into int, un-
* signed int, or double) {-->, the behavior is undefined}.
# D.8.1.2 The va_arg macro
N--> The first invocation of the va_arg macro after that of the
N--> va_start macro returns the value of the argument after that
N--> specified by parmN. Successive invocations return the values of
N--> the remaining arrguments in succession.
# D.8.1.3 The va_end {macro --> function}
* The va_end function {performs any processing so that --> facili-
* titates} a normal return {may safely occur -->} from the function
whose variable argument list was referenced by the expansion of
* va_start that initialized the va_list ap. ... {--> If} the
* va_end function {must be --> is not} invoked {after all arguments
have been accessed --> before the return, the behavior is unde-
fined}.
# D.9.1 Introduction
...
_IOFBF
which expands to an integral constant expression, suitable for
* use as the third argument to the setvbuf function {, to indicate
that full buffering is desired -->}.
Remark: The analogous phrases are deleted from the descriptions
of _IOLBF, _IONBF, SEEK_CUR, SEEK_END, and SEEK_SET.
# D.9.1 Introduction
...
SYS_OPEN
which expands to an integral constant expression that is the
* minimum number of files that {may --> the implementation guaran-
tees can} be open simultaneously.
# D.9.2 Streams
* A text stream is an ordered sequence of {bytes --> characters}
composed into "lines" ...
* A binary stream is an ordered sequence of {bytes --> characters}
that can transparently record internal data.
# D.9.2 Streams
N--> Whether a text line containing only a single space character plus
N--> a terminating new-line character is converted on input to a line
N--> consisting only of the terminating new-line character is
N--> implementation-defined.
# D.9.3 Files
If a file can support positioning requests ... then a "file
* {pointer --> position indicator}" associated with the stream is
...
Remark: This change of terminology applies throughout the sec-
tion.
# D.9.3 Files
N--> When a stream is unbuffered, characters are intended to appear
N--> from the source or at the destination as soon as written. When a
N--> stream is fully buffered, characters may be accumulated and
N--> transmitted to or from the host environment as a block when a
N--> buffer is filled. When a stream is line buffered, characters may
N--> be accumulated and transmitted to or from the host environment as
N--> a block when a new-line character is encountered or when a buffer
N--> is filled. Support for these characteristics is implementation-
N--> defined, and may be controlled via the setbuf and setvbuf func-
N--> tions.
# D.9.3 Files
N--> Whether a file of zero length (on which no characters have been
N--> written by an output stream) actually exists is implementation-
N--> defined.
# D.9.3 Files
* At program startup, three text {files --> streams} are {open -->
predefined and need not be opened explicitly} -- "standard input"
* ... "standard output" ... and "standard error" ... {--> When
opened, the standard streams are fully buffered if and only if
the stream does not refer to an interactive device.} ...
# D.9.4.1 The remove function
* The remove function returns {--> zero if the operation succeeds,}
* non-zero if {the operation --> it} fails.
# D.9.4.2 The rename function
* The rename function returns {--> zero if the operation succeeds,}
* non-zero if {the operation --> it} fails {-->, in which case if
the file existed previously it is still known by its original
name}.
N--> Among the reasons the implementation may cause the rename func-
N--> tion to fail are if the file is open or if it is necessary to
N--> copy its contents to effectuate its renaming.
# D.9.4.4 The tmpnam function
* The tmpnam function generates a string that {can safely be used
as the name of a temporary --> is not the same as the name of an
existing} file.
* ... a different {file name --> string} each time it is called
* {--> up to TMP_MAX times. If it is called more than TMP_MAX
times, the behavior is implementation-defined}.
* ... The value of the macro TMP_MAX {specifies the minimum number
of unique names that must be generated by the tmpnam function be-
fore any names repeat, which -->} shall be at least 25.
------------------------------
End of mod.std.c Digest - Thu, 15 May 86 13:28:42 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.