hfinkel added a comment. In https://reviews.llvm.org/D39611#918654, @hfinkel wrote:
> In https://reviews.llvm.org/D39611#918275, @spatel wrote: > > > Patch updated: > > I don't know if we have agreement on the behavior that we want yet, > > > I just sent a note to the Austin group mailing list to see if the POSIX folks > agree with my reading. I'll follow up. They don't, so here's a summary... 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 implementation choices allowed by C are given CX or XSI shading. Moreover, 2.3 Error Numbers, says, "Implementations may... contain extensions or limitations that prevent some errors from occurring. The ERRORS section on each reference page specifies whether an error shall be returned, or whether it may be returned. Implementations shall not generate a different error number from the ones described here for error conditions described in this volume of IEEE Std 1003.1-2001, but may generate additional errors unless explicitly disallowed for a particular function." Because 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.12 in C99 says that setting ERANGE on overflow is implementation-defined (same as in C90), but C99 TC3 and POSIX.1-2001 have math_errhandling, and there, when (math_errhandling & MATH_ERRNO) != 0, all overflows for functions in <math.h> set errno to ERANGE. 3. We can assume, for consistency, that the intent of the C standard is to allow math_errhandling, and thus associated requirements (e.g., the overflow requirements), to also apply to function in complex.h. G6p4 does say that there is an equivalence for floating-point exceptions (e.g., when (math_errhandling & MATH_ERREXCEPT) != 0), and so while errno is not explicitly discussed in this context, it is not unreasonable to assume this to be an oversight. It is also noted that in C99 Annex G was informative, not normative. So anything derived from Annex G is not a requirement until C11. 3. C11 DR#442 clarifies that, when Annex F is relevant, the definition of floating-point overflow in Annex F takes precedence over it being generically undefined in the absence of Annex F. Moreover, as clarified by C90 DR#025, where the type as infinities, all values are within the represented range, and so just the fact that an infinity is generated as a result implies that an overflow had occurred. Overflow only occurs for cases where a value is generated outside of the represented range for its type, such as when doing floating-point-to-integer conversions. But, C99 has an updated definition of overflow, and it says, 7.12.1p4, "A floating result overflows if the magnitude of the mathematical result is finite but so large that the mathematical result cannot be represented without extraordinary roundoff error in an object of the specified type." Moreover, C99's Annex F says, "The ‘‘overflow’’ floating-point exception is raised whenever an infinity - or, because of rounding direction, a maximal-magnitude finite number - is returned in lieu of a value whose magnitude is too large." While the Annex F text replaces the overflow definition, and does not mention errno explicitly, it is reasonable to assume it does not eliminate the errno-associated requirements from 7.12.1p4 intentionally. Thus, cabs is fine to set errno, as can essentially all of the other complex.h functions. > > >> but I'm updating the patch/description/title to only deal with <complex> in >> this patch and taking a shot at one interpretation, so we can see what that >> might look like. >> >> There are really 2 changes here: >> >> 1. We had all of <complex> marked constant all the time ('c'). I think >> there's agreement that can't be true by default (a platform could set errno >> on any of these calls based on the language in the C standard). >> 2. We make an exception for a GNU environment - here, the calls are always >> constant because the standard allows - and POSIX constrains - the errno >> setting behavior. This is despite the fact that glibc is known to set errno >> in some cases. https://reviews.llvm.org/D39611 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
