IBM's comments on 92-001 (FPCE)

[Fred Tydeman]

Subject: Comments on NCEG paper X3J11.1/93-001 Floating-Point C Extensions
 
Vote:  Yes, with comment.
 
The following are IBM's comments to be included with the X3 subgroup
letter ballot on X3J11.1/93-001 as amended by 93-022.
 
A general comment based upon 26. Miscellanea compiled by Rex Jaeschke
pages 248-249, The Journal of C Language Translation, Volume 3, Number 3,
December, 1991.  All dummy argument identifier names used in the C
Standard are non-conforming!  Essentially, these identifiers must
either be omitted, spelled with a leading underscore and a capital
letter, or with two leading underscores.  Therefore, you need to change
all your function prototypes.  IBM votes for adding "__" to the names.
To see why the current prototypes fail, consider:
  #define x 3
  #include <math.h>
  #define stream 3
  #include <stdio.h>
 
An alternative is to add the following paragraph after page 4, line 7:
  As in the C Standard, function prototypes are shown with dummy
  argument identifier names in the user's name space.  The real
  prototypes in the various headers would either omit the identifier, or
  add a leading '_' and capitalize the first letter, or add two leading
  '_'s to the identifier.  For example,
     double modf( double value, double *iptr );
  would be done as one of
     double modf( double, double *);
     double modf( double _Value, double *_Iptr );
     double modf( double __value, double *__iptr );
 
A second general comment:  The Floating-Point Environment is not well
defined and is incomplete.  From section 4.4 Floating-Point Environment,
fesetexcept and fesetenv set, but not raise, exceptions.  Therefore, set
cannot mean the same thing as raised.  Therefore, there must be at least
3 states (set, raised, cleared) for each exception.
 
Since 3-state is hard to do on a binary machine, it appears that each
exception has associated with it:
 1)  Set or cleared
 2)  Raised or not raised
 3)  Trap enabled or disabled
 4)  Optional information, such as:
    a) Address of the code which raised it
 
Given that a distinction has been made between set and raised, the
functions in section 4.4 are not complete.  There is no way to test what
exceptions are currently raised.  There is no way to remove a raised
exception.  The only way to restore the entire floating-point
environment is to feclearexcept(FE_ALL_EXCEPT); followed by
feupdateenv(&save_env);
 
One issue not addressed is how long is an exception raised?
 
Now, for the specific comments.
 
Page 4, line 37, Section 1.5 Definition of Terms, refers to "status
    flags" and "control modes", yet neither are defined.  So, the next
    items are needed.
 
  Page 4, line 9, need to add something like:
    Control modes -- variables that the user may set, sense, save, and
    restore to control the execution of subsequent arithmetic
    operations.  Floating-point control mode is made up of at least the
    rounding direction mode and the rounding precision mode.  An
    implementation may also have traps disabled/enabled modes (which is
    not covered by this specification).
 
  Page 4, line 51, Mode:
    Add at end of sentence: See control modes.
 
  Page 5, line 32, need to add something like:
    Status flag -- a flag signifying that a floating-point exception has
    occurred since the user last cleared it (each flag may take three
    states:  set, raised and clear).  When not cleared, a status flag
    may contain additional system-dependent information, possibly
    inaccessible to some users.  IEEE implementations support overflow,
    underflow, invalid, divide-by-zero, and inexact status flags.
 
    Another choice for this is status flags is made up of exception
    flags (raised/not raised) and 'sticky' accrued flags (set/cleared).
 
Page 15, lines 37-39, Section 3.2.1 Floating and integral
    This whole paragraph needs to be reworked for two reasons.  First,
    it is possible that infinity and/or NaN could be represented in the
    integer type; in that case there should not be an exception.
    Second, it is possible that for overflow there is an INTEGER
    overflow exception that could be raised or signaled instead of a
    FLOATING-POINT invalid operation exception.  IEEE-754, page 14,
    section 7.1 Invalid Operation, item (7) says:  "Conversion of a
    binary floating-point number to an integer or decimal format when
    overflow, infinity or NaN precludes a faithful representation in
    that format and this cannot otherwise be signaled."
 
Page 26, line 39, Section 4.2.1.2 The strtof, strtod, and strtold
functions:
    There is a difference between translation-time and execution-time
    with respect to the number of characters (digits) in a number and
    that might impact conversion.  ANSI C 2.2.4.1, page 14, line 17 has
    the minimum limit of 509 characters in a logical source line and
    line 19 has 32767 bytes in an object (such as the string passed to
    strtod).  So the string ".000...0001e32759" that is 32767 bytes long
    (... is around 32755 0's) might convert to the value 0.0 if only the
    first 509 digits are used, but convert to the value 1.0 if the full
    32767 digits are used.  The same difference might also apply to the
    scanf family.
 
Page 27, line 11, Section 4.2.1.2 The strtof, strtod, and strtold
functions:
    Is an implementation that supports sign-opt NANS(n-char-sequence-opt)
    or sign-opt NANS, for signaling NaNs, in violation of this standard?
    If so, than these two syntax forms need to be added.  If not, then a
    note should be added after line 26 on page 27 explaining that
    implementations may be extended to support signaling NaNs, and that
    the above is the syntax.  NCEG should at least standardize the syntax
    of signaling NaNs.
 
 
Page 48, lines 27-28, Section 4.3.9.2 The nan functions:
    Swap these two lines, so the float comes first.  This will then be
    consistent with 4.3.4.11 modf functions on page 41.
 
Page 53, line 44, Section 4.4.1.4 The fesetexcept function:
    Change "must" to "should".
 
Page 60, line 5, Section B.1 Expression evaluation:
    What is the rational for the statement that exceptions need not be
    precise?
 
Page 67, line 23, Section F. <fp.h> for IEEE Implementations:
    Change 'is' to 'should be' or 'is probably'.  IBM would like to
    allow inexact to not be raised in some cases.  That is, we would
    like inexact to probably be raised when it should be raised.
 
Page 67, line 40, Section F. <fp.h> for IEEE Implementations
    Does "appends to" mean that errno support is required?  I believe
    that NCEG wants errno support removed or optional.  But, I am
    afraid that someone may interpret this area as still requiring
    support for errno.
 
Page 73, line 11, Section F.4.3 The pow function:
    Add rational for why pow(+1, +/- INFINITY) is NaN, instead of +1.
 
Fred Tydeman, IBM, Austin, Texas (512) 838-3322; fax (512) 838-3484
AIX S/6000 Math library architect & IBM's rep to NCEG (X3J11.1)
Internet: tydemanaibmpa.awdpa.ibm.com    uucp: uunet!ibmsupt!tydeman