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

Thu Jan 20 06:39:24 PST 2022

Hi Jim,

This paper did not make it into the schedule for the next C meeting so it
is not a tight schedule at all. I do hope to get something in within the
next couple of weeks to make it in time for the subsequent (post February)
WG14 meeting though.

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/20/2022 12:24 AM
Subject:	[EXTERNAL] Re: [Cfp-interest 2346] Updated (V4) N2823

Rajan, the comments below are for V4. I believe most of them still apply to
V6, but they are incomplete. It will probably be Friday before I can
respond to V6 properly. How tight is your schedule on this? On Jan 19,
2022, at 3:25 PM, Rajan Bhakta ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Rajan, the comments below are for V4. I believe most of them still apply to
V6, but they are incomplete. It will probably be Friday before I can
respond to V6 properly.  How tight is your schedule on this?

      On Jan 19, 2022, at 3:25 PM, Rajan Bhakta <rbhakta at us.ibm.com> wrote:

      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

      <graycol.gif>"Jim Thomas" ---01/19/2022 04:26:12 PM---There’s no need
      to mention <math.h> in “… when <stdlib.h>, <fenv.h> and <math.h> are
      included …”. Th

      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.

Ah. I didn’t understand the whole intention for the “inclusive version”.

      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.

Regarding the [?] footnote, I don’t see that C mentions the as if rule.
Also, the C term seems to be “thread storage”. Here’s a different shot at
the footnote:

     [?] Since a conforming freestanding implementation is not required to
     accept program that use features in the contents of <errno.h>, the
     implementation need not provide thread storage for errno. Similarly,
     since a conforming freestanding implementation is not required to
     accept programs that use features in the contents of <fenv.h> for
     accessing floating-point exceptions or for changing the floating-point
     rounding mode, the implementation need not provide thread storage for
     the floating-point environment.

In 7.20 #20 we could allow freestanding implementations to define
math_errhanding to 0, to indicate that neither errno nor floating-point
exceptions are supported.

The draft footnote above doesn’t mention locales. I’m not sure what to say.

      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?

Yes. It’s for the underflow paragraph for alternative 2, for 7.22.1.5 and
7.29.4.1.1.

Matching the overflow paragraph to 7.12.1 gives

     ...; if the integer expression math_errhandling & MATH_ERRNO is
     nonzero, the integer expression errno acquires the value ERANGE; if
     the integer expression math_errhandling & MATH_ERREXCEPT is nonzero,
     the “overflow" floating-point exception is raised.

The overflow paragraph for 7.29.4.1.1 should match 7.22.1.5.

      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).

Hmm. Isn’t it substantively the same as what you have? It makes the
floating-point numeric conversion functions like the math functions with
respect to errno and floating-point exceptions. Yes, it is a change from
the current C draft. The change is like when we added floating-point
exceptions as an alternative to errno for math.h functions.

-  Jim Thomas

      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

      <N2823UpdateV6.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20220120/237f16b3/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/20220120/237f16b3/attachment-0001.gif>