delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2003/08/27/16:31:02

From: <ams AT ludd DOT luth DOT se>
Message-Id: <200308272025.h7RKPrFT003625@speedy.ludd.luth.se>
Subject: Re: Arithmetic Exceptions in C99
In-Reply-To: <3F4D011A.1080203@cyberoptics.com> "from Eric Rudd at Aug 27, 2003
02:06:02 pm"
To: djgpp-workers AT delorie DOT com
Date: Wed, 27 Aug 2003 22:25:53 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
MIME-Version: 1.0
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

According to Eric Rudd:
> I'm having trouble reconciling Annex F with the following clause from 
> the main body of C99:
> 
>     |7.12.1 Treatment of error conditions
> 
>     ||1 The behavior of each of the functions in <math.h> is specified
>     for all representable ||values of its input arguments, except where
>     stated otherwise. Each function shall execute ||as if it were a
>     single operation without generating any externally visible
>     exceptional ||conditions.|
> 
> ||||||which suggests to me that SIGFPE should not be set by the math 
> functions under any conditions.  If I am missing something, please 

(What do the pipes ("|") do there?)

I think that paragraph only applies to the valid input
arguments. I. e. if you give values which are not valid input, this
paragraph have no bearing, i. e. exception is ok.

That makes sense with regard to domain errors (e. g. calling
asin(2.0)). Especially as the next paragraph does talk about domain
errors that shall potentially (depending on the value of
math_errhandling) raise an exception.

However I don't quite see how my reasoning would legitimise raising an
exception on overflow, underflow etc. Are values that cause overflow
not "representable values of its [the function's] input arguments"?

> straighten me out, but I thought that "exception" in the context of C99 
> had to do with setting errno, rather than a low-level processor state, 
> as it seems to imply in Annex F.  Perhaps this would be a good question 
> for comp.std.c.

What text in C99 says "raising an exception" == "errno = <some
number>;" to you?

Perhaps somebody (you?) should ask for clarification on comp.std.c.

> To cause the math functions to set SIGFPE, where they previously did 
> not, could break existing code.

Again, how do you _set_ SIGFPE? I thought you raised it, i. e. calling
the signal hander somehow.

The math functions shouldn't raise SIGFPE unless something goes wrong.

> Question: Has it already been decided that DJGPP will be IEC 60559 
> compliant (that is, comply with Annex F)?

The answer is: as Annex F is normative and we want to comply to C99,
yes. (When we reach that status is a different story.)


Right,

						MartinS

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019