[Cfp-interest 2353] Re: Updated (V4) N2823

[Rajan Bhakta]

Once more into the breech! Responses inline in blue below.

(See attached file: N2823UpdateV6.html)

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative (Canada, USA), PL22.11 Chair
C/C++ Compiler Development
rbhakta at us.ibm.com

IBM



From:	"Jim Thomas" <jaswthomas at sbcglobal.net>
To:	"Rajan Bhakta" <rbhakta at us.ibm.com>
Cc:	"CFP" <cfp-interest at ucbtest.org>
Date:	01/19/2022 04:26 PM
Subject:	[EXTERNAL] Re: [Cfp-interest 2346] Updated (V4) N2823



There’s no need to mention <math.h> in “… when <stdlib.h>, <fenv.h> and
<math.h> are included …”. The “inclusive version” of Alternative 1 is
missing ", without the requirements to set errno (see 7.5) or modify the
floating-point ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
There’s no need to mention <math.h> in “… when <stdlib.h>, <fenv.h> and
<math.h> are included …”.

Agreed.

The “inclusive version” of Alternative 1 is missing ", without the
requirements to set errno (see 7.5) or modify the floating-point
environment (see 7.6),”.
I thought that was the discussion we had today. Without requiring errno.h
to be included, there is no way to access errno from a user program,
meaning we do not need to say anything about setting it as the behaviour is
not observable by a program.
That was what I had thought you meant by "not excluding". i.e. no need to
say no setting errno or modifying the floating point environment in the
normative text. I did add in a line to mention the floating-point
environment to the footnote as you suggested below.


Similar to [?] regarding errno, if the <fenv.h> functions to query flags or
modify modes are not required, the implementation does not have to maintain
thread local storage for the floating-point environment.


The following would be more parallel, and uses the same wording as for math
overflow and underflow in 7.12.1:

     ;  if the integer expression math_errhandling & MATH_ERRNO is nonzero,
     whether errno acquires the value ERANGE is implementation defined; if
     the integer expression math_errhandling & MATH_ERREXCEPT is nonzero,
     whether the "underflow" floating-point exception is raised is
     implementation-defined.

Where do you see this being added? I can't see using it in alternative 1 as
that is intended to have no error handling. Was this a proposal for
alternative 2? If so, I like it as it allows implementations to avoid the
exception case as well. This however would be a change to the existing
definition which requires ERANGE for overflow. I did want to avoid changing
the existing specification too much beyond allowing exceptions (as it seems
we do for other functions).

The (unchanged) last sentence in the last change does not match what is in
the draft.
Updated. This is probably also what Fred meant. Sorry Fred, I misunderstood
what you were referring to.


- Jim Thomas

      On Jan 19, 2022, at 11:30 AM, Rajan Bhakta <rbhakta at us.ibm.com>
      wrote:



      (See attached file: N2823UpdateV4.html)

      Regards,

      Rajan Bhakta
      z/OS XL C/C++ Compiler Technical Architect
      ISO C Standards Representative (Canada, USA), PL22.11 Chair
      C/C++ Compiler Development
      rbhakta at us.ibm.com

      IBM



      <N2823UpdateV4.html>_______________________________________________
      Cfp-interest mailing list
      Cfp-interest at oakapple.net
      http://mailman.oakapple.net/mailman/listinfo/cfp-interest


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20220119/ef78600e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20220119/ef78600e/attachment-0001.gif>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20220119/ef78600e/attachment-0001.html>