<html><body><p><font size="2" face="sans-serif">Unfortunately I don't have access to the Cell library or compiler anymore so I can't check what next* do. I do know HUGE_VAL does give infinity for double and long double, but FLT_MAX for float.</font><br><br><font size="2" face="sans-serif">Regards,<br><br></font><font size="2" face="sans-serif"><b>Rajan Bhakta</b></font><font size="2" face="sans-serif"><br>z/OS XL C/C++ Compiler Technical Architect<br>ISO C Standards Representative (Canada, USA), PL22.11 Chair<br>C/C++ Compiler Development</font><br><font size="2" face="sans-serif">rbhakta@us.ibm.com</font><br><br><font size="2" face="sans-serif">IBM</font><br><br><img width="16" height="16" src="cid:1__=8FBB0D12DFDA96998f9e8a93df938690@ibm.com" border="0" alt="Inactive hide details for "Damian McGuckin" ---11/01/2021 07:35:57 PM---Vincent, Jim, On Mon, 1 Nov 2021, Jim Thomas wrote:"><font size="2" color="#424282" face="sans-serif">"Damian McGuckin" ---11/01/2021 07:35:57 PM---Vincent, Jim, On Mon, 1 Nov 2021, Jim Thomas wrote:</font><br><br><font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">"Damian McGuckin" <damianm@esi.com.au></font><br><font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">"CFP" <cfp-interest@ucbtest.org></font><br><font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">11/01/2021 07:35 PM</font><br><font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">[EXTERNAL] [Cfp-interest 2253] Re: nextup/nextdown and HUGE_VAL definition</font><br><font size="1" color="#5F5F5F" face="sans-serif">Sent by: </font><font size="1" face="sans-serif">"Cfp-interest" <cfp-interest-bounces@oakapple.net></font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2"><br>Vincent, Jim,<br><br>On Mon, 1 Nov 2021, Jim Thomas wrote:<br><br>> I was surprised to see that C doesn?t directly define the value of <br>> HUGE_VAL. I had thought the HUGE_VAL macros gave the largest value in <br>> their type, but ... The library (in math.h and the string conversion <br>> functions) specifies them as the value to be returned if (positive) <br>> overflow occurs, and default rounding is in effect. And online <br>> references say HUGE_VAL macros give the value returned on overflow. This <br>> means an implementation that had infinities but rounded toward zero by <br>> default would define the HUGE_VAL macro to be the maximum finite value <br>> in the type.<br><br>I thought the original HUGE_VAL first appeared in System V Rel 3 Unix. It <br>was the largest finite value of the type. Never infinity.<br><br>But then, over time, on systems which supported infinities, it become the <br>same as infinity on so many systems, I started assuming it was the same as<br>INFINITY (on systems which supported infinity).<br><br>That also means that<br><br> nextUp(HUGE_VAL) == HUGE_VAL, .... if INFINITY is supported<br><br> nextUp(HUGE_VAL) == HUGE_VAL, .... if INFINITY is NOT supported<br><br> nextDown(-HUGE_VAL) == -HUGE_VAL, .... if INFINITY is supported<br><br> nextUp(-HUGE_VAL) == -HUGE_VAL, .... if INFINITY is NOT supported<br><br>so it is consistent and not some exception for nextUp (or nextDown if the <br>value is negative).<br><br>> None of these are a problem for IEC 60559 implementations and I don?t <br>> know if they are for any significant implementations.<br><br>I am curious how nextUpf()/nextDownf() work on a Cell CPU. Rajan?<br><br>>> If HUGE_VAL, HUGE_VALF and HUGE_VALL are expected to be the maximum<br>>> values of the type, then the standard should be modified everywhere<br>>> it suggests that this isn't necessarily the case.<br><br>That definitely needs to be clear and any words about this which are <br>unclear need to change.<br><br>> As for nextup/nextdown, I think they just step through representable <br>> values and were never intended to be tied to overflow or rounding <br>> direction. This argues for a change like you suggest. We might be able <br>> to present it as something less than a new proposal. A clarification of <br>> intent?<br><br>I agree that seemingly different explanations in multiple places is messy. <br>I assume that ensuring consistencyt in explanations is NOT a new proposal.<br>I like the words "clarification of intent". The world would be a better <br>place if that occurred a lot more!<br><br>Stay safe - Damian<br><br>Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037<br>Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here<br>Views & opinions here are mine and not those of any past or present employer<br>_______________________________________________<br>Cfp-interest mailing list<br>Cfp-interest@oakapple.net<br></font></tt><tt><font size="2"><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</a></font></tt><tt><font size="2"> <br></font></tt><br><br><BR>
<BR>
</body></html>