From owner-freebsd-standards@FreeBSD.ORG Wed Dec 24 01:09:47 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E53616A4CE for ; Wed, 24 Dec 2003 01:09:47 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A8B043D1F for ; Wed, 24 Dec 2003 01:09:45 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id UAA13147; Wed, 24 Dec 2003 20:09:39 +1100 Date: Wed, 24 Dec 2003 20:09:39 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Steven G. Kargl" In-Reply-To: <200312240600.hBO606TJ066756@troutmask.apl.washington.edu> Message-ID: <20031224200114.F5421@gamplex.bde.org> References: <200312240600.hBO606TJ066756@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-standards@freebsd.org Subject: Re: fenv.h implementation questions X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2003 09:09:47 -0000 On Tue, 23 Dec 2003, Steven G. Kargl wrote: > Bruce Evans wrote: > > On Sun, 21 Dec 2003, Steven G. Kargl wrote: > > > > > Is the following a sufficient implementation of fenv.h? > > > _fenv_t and _fexcept_t would be defined in machine/fenv.h, > > > which I haven't implemented, yet. I'm assuming that > > > these may be architecture specific (e.g., endianness). > > > > fenv_t and fexcept_t are very MD, and hopefully aren't needed > > in more than 1 file, so they should be declared directly in > > . > > Certainly, fenv_t and fexcept_t are MD, but I don't > believe that their use is restricted to 1 file (unless > I'm totally misinterpreting what you wrote). Consider, I checked. It is only defined in according to C99 (n869.txt draft) and and POSIX.1-2001 (draft7). > #include > #include > #include > > int foo(x) { > double x; > fexcept_t bar; > errno = 0; > x = ceil(x); > if (errno != 0) { /* FE occurred */ > fegetexception(&bar, FE_ALL_EXCEPT); > /* Do something to address FE */ > } else { > .... > } > } You got it from there. It is not in though. > (snip) > > > > #ifdef _EXCEPTIONS > > > #define FE_DIVBYZERO 0x00000001 /* Divide by zero */ > > > #define FE_INEXACT 0x00000002 /* Inexact flag raised */ > > > #define FE_INVALID 0x00000004 /* Invalid operation */ > > > #define FE_OVERFLOW 0x00000008 /* Overflow */ > > > #define FE_UNDERFLOW 0x00000010 /* Underflow */ > > > #define FE_ALL_EXCEPT 0x0000001F /* Bitwise-or of above flags */ > > > #endif /* _EXCEPTIONS */ > > > > > > #ifdef _ROUNDING_MODES > > > #define FE_DOWNWARD 0x00000020 /* Round downward */ > > > #define FE_TONEAREST 0x00000040 /* Round to nearest */ > > > #define FE_TOWARDZERO 0x00000080 /* Round towards zero */ > > > #define FE_UPWARD 0x00000100 /* Round upwards */ > > > #endif /* _ROUNDING_MODES */ > > > > These should probably all be MD. It saves a negative amount of code to > > use a common definition since larger code would be required to convert > > between the MI bits and the MI bits. > > > > I'll have to look at SuSv3 again, but the above definitions > should be suitable for both big and little endian machines. > I'm not sure about 32 bit versus 64 bit machines. Are you > concerned that an architecture may only support a subset of > the above flags? Each arch has its own natural definitions of the flags. E.g., on i386's the natural division by 0 flag is FP_X_DZ = 0x04, not 0x00000001. Bruce