JTC1/SC22/WG14
N768
N768 Current C9X Tweak List N768
J11/97-132 23-Sep-97 J11/97-132
Tom MacDonald
[email protected]
The following are a set of proposed "Tweaks" to the Draft. None are
considered to be substantive changes. Any tweak that is likely to be a
substantive change is marked as a substantiative change. Any change marked
OPEN ISSUE has not been changed in C9XD11P3. Please review the following
list and see if you have any objections to these changes.
------------------------------------------------------------------------
6.5.5 Declarators
[#5] If, in the declaration ``T D1,'' D1 has the form
( D )
then ident has the type specified by the declaration ``T
D.'' Thus, a declarator in parentheses is identical to the
unparenthesized declarator, but the binding of complex
declarators may be altered by parentheses. ^^^^^^^
The word "complex" should now be "complicated" to avoid confusion with
the complex basic types.
STATUS: OPEN ISSUE
------------------------------------------------------------------------
Fred T.
5.2.4.2.2 <float.h>
Example 2 refers to ANSI/IEEE 754-1985. That should
be changed to ISO 559-1989
Update: C9XD11P3 says ISO 559, should this be ISO 559-1989?
STATUS: OPEN ISSUE
------------------------------------------------------------------------
Fred T.
In annex F on IEC 559 floating-point,
in F.9.3.4 The frexp function,
change scalb to scalbn.
STATUS: Fixed in C9XD11P3
------------------------------------------------------------------------
Fred T.
In looking at draft 10 at the ftp site, I do not see a formal
reference to IEC 559. Should it be added to Clause 2 Normative
references, or to Annex A Bibliography?
Where ever it goes, it is:
IEC 559 Second edition 1989-01 Binary floating-point arithmetic
for microprocessor systems.
>>>>>> Doug Gwyn
I think the IEC 559 reference goes in the Bibliography,
since it is not normative on all conforming implementations.
I also have a note on my copy of Draft 10 to remind everyone
that we ought to have a reference to the previous C standard
in the Bibliography.
------------------------------------------------------------------------
Jim T.
7.7.9.7 (Draft 11-pre1) The round function
The Description heading is missing.
STATUS: OPEN ISSUE
------------------------------------------------------------------------
Fred T.
In section 7.6.1, paragraph 2, change
"The effect of one of this pragma in any other context is undefined."
to either:
"The effect of one of these pragmas in any other context is undefined."
or
"The effect of this pragma in any other context is undefined."C
STATUS: OPEN ISSUE
------------------------------------------------------------------------
Douglas A. Gwyn
Well, if you want to allow volatile qualification inside the typedef
for sig_atomic_t, which is unnecessary (even the C89 standard shows
an explicit separate "volatile" when sig_atomic_t is used), then we
still need a global statement for the other typedefs in the standard
headers. It is absolutely wrong, for example, for any of them to
include const qualification, but there is no prohibition of that in
the current draft.
So amend my suggested wording for 7.1.2 to:
Declarations of types described in this clause shall not
include type qualifiers, unless explicitly stated otherwise.
STATUS: OPEN ISSUE
------------------------------------------------------------------------
Fred J. Tydeman said:
> In the library summary, for at least <math.h> and <complex.h>,
> do we need to list the float and the long double versions of
> the functions? Or, is just the current list of double functions
> sufficient?
Clive said:
> I would say that they should be listed, since they're required (if I'm
> reading the text correctly).
STATUS: OPEN ISSUE
------------------------------------------------------------------------
Fred J. Tydeman said:
> Annex F - Add to ilogb: A domain error may occur if x is zero.
#### The description of "logb" says "A range error may occur if the
#### argument is zero." So why is this a domain error?
#### Also, should "ilogb" have the same range error as part of its
#### description? -- TMacD
STATUS: OPEN ISSUE
------------------------------------------------------------------------
Fred J. Tydeman said:
In F.3 Operators and functions, 9th bulleted item, change:
The translation time conversion of floating-point constants
and the strtod, fprintf, and related library functions in
<stdlib.h> and <stdio.h> provide ...
to
The translation time conversion of floating-point constants
and the strtod, fprintf, fscanf, and related library functions in
<stdlib.h>, <stdio.h>, and <wchar.h> provide ...
STATUS: OPEN ISSUE
------------------------------------------------------------------------
Fred T.
7.6.4.4 The feupdateenv function
Change:
The feupdateenv function saves the current exceptions ...
to:
The feupdateenv function saves the current raised exceptions ...
STATUS: OPEN ISSUE
------------------------------------------------------------------------
Fred T.
In 7.7.9.9 llround function,
change "lroundtol" to "lround".
STATUS: Fixed in C9XD11P3
------------------------------------------------------------------------
Clive Feather
Substantive Change
One for the nits file: the title of 6.5.6 is "Type definitions", but the
body talks about declarations. The latter term is correct, because no
storage is reserved.
STATUS: OPEN ISSUE
------------------------------------------------------------------------
Jim T.
Page 3, 3.7 Correctly rounded result
Change "the result" to "a floating-point result".
STATUS: OPEN ISSUE
------------------------------------------------------------------------
Jim T.
Page 442, F.3 Operators and functions
In the eighth bullet, change "The lrint and llrint functions can be used in
conjunction with casts to provide IEC 559 conversions ..." to "The lrint
and llrint functions can be used to implement IEC 559 conversions ...". As
is it suggests an incorrect (i.e. non IEEE) implementation.
STATUS: OPEN ISSUE