ISO/ IEC JTC1/SC22/WG14 N768

       N768               Current C9X Tweak List         N768
       J11/97-132               23-Sep-97                J11/97-132

                              Tom MacDonald
                              tam@cray.com


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