From: Message-Id: <200308221711.h7MHBeCL021198@speedy.ludd.luth.se> Subject: Re: Arithmetic Exceptions in C99 In-Reply-To: <1d9.f96c51c.2c767308@aol.com> "from Kbwms@aol.com at Aug 21, 2003 03:10:00 pm" To: djgpp-workers AT delorie DOT com Date: Fri, 22 Aug 2003 19:11:40 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL78 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-MailScanner: Found to be clean Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk According to Kbwms AT aol DOT com: > In a recent communication with Eli Zaretskii, the problem of raising > arithmetic exceptions, as described in C99, arose. His latest thoughts are appended > to this email as a postscript. Paragraph F.9 of C99 is attached to this email > for those who do not have C99 on their system. Is that from the real C99 or from the draft you refer to below as C99? > In C99, functions nearbyint are specifically prohibited from endangering the > setting of the inexact exception. I am not aware of any other functions where > a similar restriction exists. So, what do we do about exceptions? Except I think they specifically point out that because if you round you are making the result inexact (so a inexact exception is plausible), but as you are asking for rounding you should not get that exception in this case. > For those who have been pining for a copy of C99, here is a link: > > http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/ That isn't C99. That's a draft. According to comp.std.c real changes were made after that draft. You shouldn't advertise it as C99. (But it's the best that is freely available.) > In a message dated 8/21/2003 9:57:50 AM Eastern Standard Time, > eliz AT elta DOT co DOT il writes: > > The main issue, as far as I'm concerned, is this: when C99 says > > ``raises such-and-such exception'', does that mean that we need to > > actually trigger a SIGFPE, or merely that the appropriate bit in > > fexcept_t should be set? It sure sounds like SIGFPE should be triggered. How is setting a bit somewhere "raising an exception"? Right, MartinS