On Thu, 9 Nov 2017, Hal Finkel wrote:
Forwarded Message
...
From Jim Thomas. I???ll leave it to you to forward this to Austin Group.
Hal is correct, and I think the response to him misses the
point that he raised.
Agreed.
What Hal was talking about was the fact
On Thu, 9 Nov 2017, Joseph Myers wrote:
On Thu, 9 Nov 2017, Hal Finkel wrote:
Thus, neither cabs, nor most other math.h/complex.h functions taking
floating-point inputs and producing a floating-point output, should ever
formally overflow (because even infinity lies within the represented
On 11/09/2017 05:43 PM, Joseph Myers wrote:
On Thu, 9 Nov 2017, Hal Finkel wrote:
Thus, neither cabs, nor most other math.h/complex.h functions taking
floating-point inputs and producing a floating-point output, should ever
formally overflow (because even infinity lies within the represented
On Thu, 9 Nov 2017, Hal Finkel wrote:
> Thus, neither cabs, nor most other math.h/complex.h functions taking
> floating-point inputs and producing a floating-point output, should ever
> formally overflow (because even infinity lies within the represented set), and
> so shouldn't set ERANGE
FYI
Forwarded Message
Subject:RE: complex.h functions and errno
Date: Thu, 9 Nov 2017 11:38:54 -0700
From: Barry Hedquist <b...@peren.com>
Reply-To: b...@peren.com
Organization: Perennial, Inc
To: 'Jim Thomas' <jaswtho...@sbcglobal.net>, '
no errors are defined, and POSIX contains no specific
prohibition on the complex.h functions returning errors via errno, no
restriction on these functions setting errno is implied.
Thus, if C says that an implementation can set errno for functions in
complex.h, POSIX does not restrict that.
2. 7
Bruce Evans wrote, on 10 Nov 2017:
>
> The meta-rules in C99 and C11 are:
> - F.9p4 requires (math_errhandling & MATH_ERREXCEPT) != 0. (MATH_ERROR
> seems to be allowed, but is not normally.)
> - F.9p6 defines "overflow" to have normal semantics. In particular,
>
On Fri, 10 Nov 2017, Bruce Evans wrote:
> Hmm, POSIX has the caveat that functions might never see signaling NaNs
> since parameter passing might turn them into quiet NaNs (and raise an
> exception). I'm used to i387 floating point where this tends to always
So indeed does TS 18661-1
On Wed, 8 Nov 2017, Joseph Myers wrote:
On Wed, 8 Nov 2017, Bruce Evans wrote:
This is without Annex F (IEEE754/IOCmumble bindings). With Annex F,
Actually Annex G (F is for plain floating point types and G is for complex
floating point types).
cabs() is specified in terms of hypot() and
On Wed, 8 Nov 2017, Don Cragun wrote:
> Hi Hal,
> I agree with what others have already said in this thread, but I think
> there is a more basic issue at play here. In the example you provided:
> cabs(1.7e308+I*1.7e308);
> the multiplication is not being performed by the function. It is
Hi Hal,
I agree with what others have already said in this thread, but I think there is
a more
basic issue at play here. In the example you provided:
cabs(1.7e308+I*1.7e308);
the multiplication is not being performed by the function. It is performed by
the compiler evaluating arguments
On Wed, 8 Nov 2017, Bruce Evans wrote:
> This is without Annex F (IEEE754/IOCmumble bindings). With Annex F,
> cabs() is specified in terms of hypot() and atan2(), so math_errhandling
> accidentally applies to it (via the hypot() part). However, overflow is
I think that specification is only
When POSIX says "No errors are defined" for a C standard header,
that defers to the C standard doesn't require errno be set to specific
values, but a POSIX implementation can still elect to set errno due to
the 7.3.2 clause. Places where POSIX overrides the C standard get
the CX or XSI shading,
On Tue, 7 Nov 2017, Hal Finkel wrote:
My reading of the combined C and POSIX specifications leads me to believe
that functions in complex.h don't set errno on POSIX systems. This came up
recently during a code review for the Clang compiler [1]. It has been pointed
out that, under glibc,
14 matches
Mail list logo