[Cfp-interest 2165] Freestanding with FP binding - wording take 2
Rajan Bhakta
rbhakta at us.ibm.com
Wed Sep 29 14:43:55 PDT 2021
This is the paper I intend to send to WG14 on behalf of CFP as per my
action item from todays meeting:
Some members of the WG21 committee seem to be concerned with the expansion
in scope in freestanding environments in C23 due to the changes brought in
from the integration of TS 18661. This paper tries to address the concerns
brought forward in WG14 reflector messages 19444 and 19445.
Two alternatives are proposed. The first one is intended to reduce the
scope of changes brought in by the TS to remove requirements for thread
local storage (errno) and modification to global state (the floating point
environment), and does so in a general way. The second alternative is to
let implementations choose between having errno or modifying global state
(the floating point exception states) or both where possible, and does so
by modifying functions that require errno directly. Note that the second
alternative does not remove the need to modify global state in cases
outside certain functions. For example, setting and clearing floating point
exception flags are required.
Note for alternative 1: The practical set of functions in the fenv.h header
seem to be only fegetround and fe_dec_getround, but the other query
functions were listed as well since they do not modify global state either.
The reduced list of functions is a possibility as well if alternative 1 is
chosen.
Alternative 1: In N2596, change Section 4#7 to:
The strictly conforming programs that shall be accepted by a conforming
freestanding implementation that defines __STDC_IEC_60559_BFP__ or
__STDC_IEC_60559_DFP__ may also use features, without the requirements to
set errno (see 7.5) or modify the floating point environment (see 7.6) in
the following:
- all the macros and the following functions in <fenv.h>: fegetexceptflag,
fetestexceptflag, fetestexcept, fegetmode, fegetround, fe_dec_getround,
fegetenv
- <math.h>
- the numeric conversion functions (7.22.1) of the standard header
<stdlib.h>
All identifiers that are reserved when <stdlib.h> is included in a hosted
implementation are reserved when it is included in a freestanding
implementation.
Alternative 2: In N2596 change 7.22.1.5#10 to:
The functions return the converted value, if any. If no conversion could be
performed, zero is returned. If the correct value overflows and default
rounding is in effect (7.12.1), plus or minus HUGE_VAL, HUGE_VALF, or
HUGE_VALL is returned (according to the return type and sign of the value);
the value of the macro ERANGE is stored in errno if the integer expression
math_errhandling & MATH_ERRNO is nonzero; and the "overflow" floating-point
exception is raised if the integer expression math_errhandling &
MATH_ERREXCEPT is nonzero.
If the result underflows (7.12.1), the functions return a value whose
magnitude is no greater than the smallest normalized positive number in the
return type; whether errno acquires the value ERANGE if the integer
expression math_errhandling & MATH_ERRNO is nonzero is implementation
defined. If the integer expression math_errhandling & MATH_ERREXCEPT is
nonzero, whether the "underflow" floating-point exception is raised is
implementation-defined.
Change 7.22.1.6#7 to:
The strtodN functions return the correctly rounded converted value, if any.
If no conversion could be performed, the value of the triple (+1, 0, 0) is
returned. If the correct value overflows:
- the value of the macro ERANGE is stored in errno if the integer
expression math_errhandling & MATH_ERRNO is nonzero
- the "overflow" floating-point exception is raised if the integer
expression math_errhandling & MATH_ERREXCEPT is nonzero
If the result underflows (7.12.1), whether errno acquires the value ERANGE
if the integer expression math_errhandling & MATH_ERRNO is nonzero is
implementation defined. If the integer expression math_errhandling &
MATH_ERREXCEPT is nonzero, whether the "underflow" floating-point exception
is raised is implementation-defined.
Change 7.22.1.7#8 to:
The strtol, strtoll, strtoul, and strtoull functions return the converted
value, if any. If no conversion could be performed, zero is returned. If
the correct value is outside the range of representable values, LONG_MIN,
LONG_MAX, LLONG_MIN, LLONG_MAX, ULONG_MAX, or ULLONG_MAX is returned
(according to the return type and sign of the value, if any), and:
- the value of the macro ERANGE is stored in errno if the integer
expression math_errhandling & MATH_ERRNO is nonzero
- the "overflow" floating-point exception is raised if the integer
expression math_errhandling & MATH_ERREXCEPT is nonzero
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
----- Forwarded by Rajan Bhakta/Houston/IBM on 09/29/2021 04:08 PM -----
From: "Jim Thomas" <jaswthomas at sbcglobal.net>
To: "Rajan Bhakta" <rbhakta at us.ibm.com>
Date: 09/28/2021 04:28 PM
Subject: [EXTERNAL] Re: [Cfp-interest 2140] Freestanding with FP binding
- wording
On Sep 28, 2021, at 1:47 PM, Rajan Bhakta <rbhakta at us.ibm.com> wrote: From:
"Jim Thomas" <jaswthomas at sbcglobal.net> To: "Rajan Bhakta"
<rbhakta at us.ibm.com> Date: 09/28/2021 12:27 PM Subject:
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
On Sep 28, 2021, at 1:47 PM, Rajan Bhakta <rbhakta at us.ibm.com> wrote:
From: "Jim Thomas" <jaswthomas at sbcglobal.net>
To: "Rajan Bhakta" <rbhakta at us.ibm.com>
Date: 09/28/2021 12:27 PM
Subject: [EXTERNAL] Re: [Cfp-interest 2140] Freestanding with FP
binding - wording
On Sep 17, 2021, at 8:43 AM, Rajan Bhakta <rbhakta at us.ibm.com> wrote:
Here are some words for both alternatives listed in CFP 2085
(attached) below.
Note that the words for alternative (1) can be further specified in
terms of actual changes to all the specification for the contents of
the headers that we now allow in fenv.h and math.h and stdlib,h, but
I think that would reduce clarity and be more fragile and prone to
error. Hence a minimal change is proposed alone.
For alternative (1), in N2596, change Section 4#7 from:
The strictly conforming programs that shall be accepted by a
conforming freestanding implementation that defines
__STDC_IEC_60559_BFP__ or __STDC_IEC_60559_DFP__ may also use
features in the contents of the standard headers <fenv.h> and
<math.h> and the numeric conversion functions (7.22.1) of the
standard header <stdlib.h>. All identifiers that are reserved when
<stdlib.h> is included in a hosted implementation are reserved when
it is included in a freestanding implementation.
to:
The strictly conforming programs that shall be accepted by a
conforming freestanding implementation that defines
__STDC_IEC_60559_BFP__ or __STDC_IEC_60559_DFP__ may also use
features in the contents of the standard headers <fenv.h> and
<math.h> and the numeric conversion functions (7.22.1) of the
standard header <stdlib.h>
without the requirements to set errno (see 7.5), or modify the
floating point environment (see 7.6)
. All identifiers that are reserved when <stdlib.h> is included in a
hosted implementation are reserved when it is included in a
freestanding implementation.
I believe the qualification “without” applies to “features” but
they’re far enough apart to be confusing.
<Rajan> I can kind of see that. How about the following:
The strictly conforming programs that shall be accepted by a
conforming freestanding implementation that defines
__STDC_IEC_60559_BFP__ or __STDC_IEC_60559_DFP__ may also use
features
, without the requirements to set errno (see 7.5),
Omit the comma.
or modify the floating point environment (see 7.6), in the following:
- all the macros and the following functions in <fenv.h>:
fegetexceptflag, fetestexceptflag, fetestexcept, fegetmode,
fegetround, fe_dec_getround, fegetenv
- <math.h>
- the numeric conversion functions (7.22.1) of the standard header
<stdlib.h>
All identifiers that are reserved when <stdlib.h> is included in a
hosted implementation are reserved when it is included in a
freestanding implementation.
Yes, this is better.
</Rajan>
I don’t think we need to say anything about errno not being set,
because on freestanding implementations the program can’t use
<errno.h> features. Right?
<Rajan/> I think we do need to say it, because "errno" is talked
about in the features (functions) of math.h and hence we need to be
explicit it is not included in the "use features" part.
Does the restriction on modifying the floating-point environment
apply to translation and execution? What features from <fenv.h> could
the program use? If the only usable features are queries, there
isn’t an issue with modifying the environment. If we could say which
<fenv.h> features were useable, we wouldn’t have to say anything
about removed requirements.
<Rajan> Yes, the modifications apply to execution.
Not to translation? This is relevant to whether the rounding mode pragmas
can be used.
I would propose that testing the exception flags and other query
functions should be allowed since none of those modifies the
environment. This was added to the proposed change above. I left the
"modify the floating point environment" present to ensure readers
know we are not looking to have a requirement for additional state
for freestanding. i.e. The query functions could return the defaults
for the environment and since no changes are allowed, the functions
would be the equivalent of something translation time resolved like
macros.
</Rajan>
I’m thinking the only two <fenv.h> functions that are potentially useful
are fegetround and fe_dec_getround, given that the implementation can’t
change the floating-point environment. For example, fegetmode returns an
opaque representation of the modes that is good only for an argument to
fesetmode. And there’s no point in testing for exception flags if the
implementation isn’t required to set them.
For alternative (2), in N2596, change 7.22.1.5#10 (and similar
changes for the rest of the family of functions) from:
The functions return the converted value, if any. If no conversion
could be performed, zero is returned. If the correct value overflows
and default rounding is in effect (7.12.1), plus or minus HUGE_VAL,
HUGE_VALF, or HUGE_VALL is returned (according to the return type and
sign of the value), and the value of the macro ERANGE is stored in
errno. If the result underflows (7.12.1), the functions return a
value whose magnitude is no greater than the smallest normalized
positive number in the return type; whether errno acquires the value
ERANGE is implementation-defined.
to:
The functions return the converted value, if any. If no conversion
could be performed, zero is returned. If the correct value overflows
and default rounding is in effect (7.12.1), plus or minus HUGE_VAL,
HUGE_VALF, or HUGE_VALL is returned (according to the return type and
sign of the value), and the value of the macro ERANGE is stored in
errno
if the integer expression math_errhandling & MATH_ERRNO is nonzero.
If the integer expression math_errhandling & MATH_ERREXCEPT is
nonzero, the "overflow" floating-point exception is raised.
If the result underflows (7.12.1), the functions return a value whose
magnitude is no greater than the smallest normalized positive number
in the return type; whether errno acquires the value ERANGE
if the integer expression math_errhandling & MATH_ERRNO is nonzero
is implementation defined. If the integer expression math_errhandling
& MATH_ERREXCEPT is nonzero, whether the "underflow" floating-point
exception is raised
is implementation-defined.
Since all this is in one paragraph, it might help to group related
sentences with semicolons, something like
If the correct value overflows and default rounding is in effect
(7.12.1), plus or minus HUGE_VAL, HUGE_VALF, or HUGE_VALL is returned
(according to the return type and sign of the value); the value of
the macro ERANGE is stored in errno if the integer expression
math_errhandling & MATH_ERRNO is nonzero; and the "overflow"
floating-point exception is raised if the integer expression
math_errhandling & MATH_ERREXCEPT is nonzero.
and similarly for underflows.
<Rajan/> Hmmm, it can be possibly worded better, but I think we can
leave this to the editor. I'm not sure the semicolon approach is
better.
As written, the sentence
"If the integer expression math_errhandling & MATH_ERREXCEPT is nonzero,
the "overflow" floating-point exception is raised.”
would apply whether or not overflow occurs. Likewise for underflow.
Wouldn't this mean <stdlib.h> would have to define MATH_ERRNO, etc.?
A different approach would be to define STDLIB_ERRNO, etc. and refer
to them instead of MATH_ERRNO, etc..
<Rajan/> True. I missed this. I think defining MATH_ERRNO in stdlib.h
is probably better than adding in text for a new macro.
- Jim
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>"Rajan Bhakta" ---08/05/2021 02:19:59 PM---Looking at
the specification, I think the only thing that really works is to do
something like the f
From: "Rajan Bhakta" <rbhakta at us.ibm.com>
To: cfp-interest at oakapple.net
Date: 08/05/2021 02:19 PM
Subject: [EXTERNAL] [Cfp-interest 2085] Freestanding with FP binding
Sent by: "Cfp-interest" <cfp-interest-bounces at oakapple.net>
Looking at the specification, I think the only thing that really
works is to do something like the following: 1) Say for freestanding
that error conditions do not necessarily have to be handled
(including setting errno). This would have the
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Looking at the specification, I think the only thing that really
works is to do something like the following:
1) Say for freestanding that error conditions do not necessarily have
to be handled (including setting errno). This would have the new side
effect of not requiring using exceptions as well.
or
2) Change the strtod family of functions to allow exceptions to be
used for error reporting instead of just errno. This would be a
change to the general C standard, but likely more palatable.
With regards to the whitespace and decimal point scanning, as long as
we allow a freestanding implementation to have just the C locale (as
it is now) and a single fixed code page, I think it would work for
freestanding. The issues described in WG14 19444 still apply however
meaning the code is not necessarily portable, but this may be
something we either accept, or mandate that the C locale must be
used.
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
_______________________________________________
Cfp-interest mailing list
Cfp-interest at oakapple.net
http://mailman.oakapple.net/mailman/listinfo/cfp-interest
_______________________________________________
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/20210929/2f22dbb9/attachment-0001.htm>
More information about the Cfp-interest
mailing list