X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f From: Kbwms AT aol DOT com Message-ID: <5a.240b82cc.2cd980ed@aol.com> Date: Tue, 4 Nov 2003 17:23:41 EST Subject: Re: C99 Functions Under Development and Checkout To: djgpp-workers AT delorie DOT com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_5a.240b82cc.2cd980ed_boundary" X-Mailer: 8.0 for Windows sub 6021 Reply-To: djgpp-workers AT delorie DOT com --part1_5a.240b82cc.2cd980ed_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Rich Dawe: That pretty much covers my thinking to date on the matter. Keep in mind that math_errhandling can be either MATH_ERRNO or MATH_ERREXCEPT or _both_ and remains constant for the duration of the program. This seems to imply that user must be provided some ability to set math_errhandling at startup. On the other hand, if some miscreant user decides to define an identifier with the name math_errhandling, all bets are off (the behavior is undefined). What this means is that a user must be given the opportunity to set math_errhandling once only. It is preferable that math_errhandling be an inviolate global variable rather than be available only through function linkage. Thanks for your thoughtful response. KB Williams In a message dated 11/4/2003 3:02:12 PM Eastern Standard Time, rich AT phekda DOT freeserve DOT co DOT uk writes: > As I interpret it: > > An "identifier with external linkage" in this case would be a global > variable. > > I guess the two options you have are: > > (1) In a new source module define a library internal function to return the > error-handling status. E.g.: > > #include > > static const int __math_errhandling = MATH_ERRNO|MATH_ERREXCEPT; > > int __get_math_errhandling (void) > { > return __math_errhandling; > } > > Then in define the macro to call the function: > > extern int __get_math_errhandling(void); > #define math_errhandling (__get_math_errhandling()); > > (2) Just define the macro: > > #define math_errhandling (MATH_ERRNO|MATH_ERREXCEPT) > > I prefer (1), because it keeps the details out of . > --part1_5a.240b82cc.2cd980ed_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Rich Dawe:

That pretty much covers my thinking to date on the matter.  Keep in min= d that math_errhandling can be either MATH_ERRNO or MATH_ERREXCEPT
or _both_ and remains constant for the duration of the program.  This s= eems to imply that user must be provided some ability to set math_errhandlin= g at startup.  On the other hand, if some miscreant user decides to def= ine an identifier with the name math_errhandling, all bets are off (the beha= vior is undefined).

What this means is that a user must be given the opportunity to set math_err= handling once only.

It is preferable that math_errhandling be an inviolate global variable rathe= r than be available only through function linkage.


Thanks for your thoughtful response.


KB Williams


In a message dated 11/4/2003 3:02:12 PM Eastern Standard Time, rich AT phekda DOT f= reeserve.co.uk writes:

As I interpret it:

An "identifier with external linkage" in this case would be a global variabl= e.

I guess the two options you have are:

(1) In a new source module define a library internal function to return the<= BR> error-handling status. E.g.:

#include <math.h>

static const int __math_errhandling =3D MATH_ERRNO|MATH_ERREXCEPT;

int __get_math_errhandling (void)
{
return __math_errhandling;
}

Then in <math.h> define the macro to call the function:

extern int __get_math_errhandling(void);
#define math_errhandling (__get_math_errhandling());

(2) Just define the macro:

#define math_errhandling (MATH_ERRNO|MATH_ERREXCEPT)

I prefer (1), because it keeps the details out of <math.h>.


 --part1_5a.240b82cc.2cd980ed_boundary--