From owner-freebsd-standards@FreeBSD.ORG Tue Dec 23 22:00:09 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 A82A916A4CF for ; Tue, 23 Dec 2003 22:00:09 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6093443D49 for ; Tue, 23 Dec 2003 22:00:07 -0800 (PST) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) hBO6065x066757; Tue, 23 Dec 2003 22:00:06 -0800 (PST) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost)hBO606TJ066756; Tue, 23 Dec 2003 22:00:06 -0800 (PST) (envelope-from kargl) From: "Steven G. Kargl" Message-Id: <200312240600.hBO606TJ066756@troutmask.apl.washington.edu> In-Reply-To: <20031222182536.C7679@gamplex.bde.org> To: Bruce Evans Date: Tue, 23 Dec 2003 22:00:06 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 06:00:09 -0000 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, #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 { .... } } (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? -- Steve http://troutmask.apl.washington.edu/~kargl/