Re: Fwd: RE: complex.h functions and errno

2017-11-09 Thread Bruce Evans
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

Re: complex.h functions and errno

2017-11-09 Thread Bruce Evans
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

Re: complex.h functions and errno

2017-11-09 Thread Hal Finkel
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

Re: complex.h functions and errno

2017-11-09 Thread Joseph Myers
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

Fwd: RE: complex.h functions and errno

2017-11-09 Thread Hal Finkel
FYI Forwarded Message Subject:RE: complex.h functions and errno Date: Thu, 9 Nov 2017 11:38:54 -0700 From: Barry Hedquist Reply-To: b...@peren.com Organization: Perennial, Inc To: 'Jim Thomas' , 'David Keaton'

Re: complex.h functions and errno

2017-11-09 Thread Hal Finkel
Hi, Geoff, Bruce, Joseph, et al., Thanks for responding! This is very informative. Let me attempt to summarize... 1. It is not the intent of POSIX to restrict implementation choices here made available by the C specification. Oversights aside, places where POSIX intentionally restricts

Event [Austin Group teleconference +1-888-426-6840 PIN: 2115756] 2017-11-16 at 11:00 America/New_York created

2017-11-09 Thread Single UNIX Specification
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.18// CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York X-LIC-LOCATION:America/New_York BEGIN:STANDARD DTSTART:20171105T02 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 RDATE:20181104T02

Re: complex.h functions and errno

2017-11-09 Thread Geoff Clare
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, >

Re: complex.h functions and errno

2017-11-09 Thread Joseph Myers
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

Re: complex.h functions and errno

2017-11-09 Thread Bruce Evans
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

Re: complex.h functions and errno

2017-11-09 Thread Joseph Myers
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