From owner-freebsd-standards@FreeBSD.ORG Sun Nov 30 12:58:05 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 C387116A4CE for ; Sun, 30 Nov 2003 12:58:05 -0800 (PST) Received: from web13407.mail.yahoo.com (web13407.mail.yahoo.com [216.136.175.65]) by mx1.FreeBSD.org (Postfix) with SMTP id 1CDC843FA3 for ; Sun, 30 Nov 2003 12:58:03 -0800 (PST) (envelope-from giffunip@yahoo.com) Message-ID: <20031130205803.83961.qmail@web13407.mail.yahoo.com> Received: from [63.171.232.170] by web13407.mail.yahoo.com via HTTP; Sun, 30 Nov 2003 20:58:03 GMT Date: Sun, 30 Nov 2003 20:58:03 +0000 (GMT) From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" To: freebsd-standards@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: libc should provide ftw/nftw (from NetBSD's PR database) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: giffunip@asme.org List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2003 20:58:05 -0000 Hi; Someone might want to contact the author of this NetBSD PR: http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=18378 The author is working on Debian-NetBSD and his website seems to be temporarily down, but when I emailed him last year he was willing to contribute to FreeBSD too. cheers, Pedro. ________________________________________________________________________ Download Yahoo! Messenger now for a chance to win Live At Knebworth DVDs http://www.yahoo.co.uk/robbiewilliams From owner-freebsd-standards@FreeBSD.ORG Sun Nov 30 13:42:23 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 B2C8A16A4CE for ; Sun, 30 Nov 2003 13:42:23 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-121-163-164.dsl.pltn13.pacbell.net [68.121.163.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2C6843FDF for ; Sun, 30 Nov 2003 13:42:21 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.9/8.12.9) with ESMTP id hAULdpen037486; Sun, 30 Nov 2003 13:39:52 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.9/8.12.9/Submit) id hAULdprw037485; Sun, 30 Nov 2003 13:39:51 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Sun, 30 Nov 2003 13:39:51 -0800 From: David Schultz To: Steve Kargl Message-ID: <20031130213951.GA37082@VARK.homeunix.com> Mail-Followup-To: Steve Kargl , freebsd-standards@FreeBSD.ORG References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129080911.GA25448@VARK.homeunix.com> <20031129163105.GA32651@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031129163105.GA32651@troutmask.apl.washington.edu> cc: freebsd-standards@FreeBSD.ORG Subject: Re: Implementing C99's roundf(), round(), and roundl() 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: Sun, 30 Nov 2003 21:42:23 -0000 On Sat, Nov 29, 2003, Steve Kargl wrote: > On Sat, Nov 29, 2003 at 12:09:11AM -0800, David Schultz wrote: > > On Fri, Nov 28, 2003, Steve Kargl wrote: > > > Can the math functions round[fl]() be implemented in > > > terms of other math(3) functions and still conform to the > > > C99 and POSIX standard? For example, > > > > > > #include > > > > > > float roundf(float x) { > > > float t; > > > if (x >= 0.0) { > > > t = ceilf(x); > > > if ((t - x) > 0.5) t -= 1.0; > > > return t; > > > } else { > > > t = ceilf(-x); > > > if ((t + x) > 0.5) t -= 1.0; > > > return -t; > > > } > > > } > > > > This looks correct to me at first glance, modulo possible problems > > with overflow. It's valuable to have simple MI implementations of > > these functions to avoid hampering efforts to port FreeBSD to new > > architectures. Faster MD versions can always be added later. (I > > noticed the other day that Intel has actually released an > > optimized IA64 libm, which we should consider importing.) > > I don't undrestand your overflow comment. ceil[f]() can return Inf > and nan, but in those cases round[f]() should also return Inf and nan. > The two operations, (t-x) and (t+x), should yield a value in the > range [0,1). I'll submit a PR with a man page. The concern was that ceil() could round a number up to infinity when round() is supposed to round the number down. But now that I think about it at a reasonable hour, this concern is clearly bogus. In base two floating point representations, there isn't enough precision to get numbers that large with nonzero fractional parts. > As a side comment, we need to start coding the missing C99 math(3) > functions because GCC is moving to using these in their CVS > development trees. Really? Which ones? I don't think I'll have time to deal with this until January, but then again, we're not doing another gcc import before then. From owner-freebsd-standards@FreeBSD.ORG Sun Nov 30 14:10:25 2003 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F8CA16A4D0 for ; Sun, 30 Nov 2003 14:10:25 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEA3A43FA3 for ; Sun, 30 Nov 2003 14:10:24 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hAUMAOFY083129 for ; Sun, 30 Nov 2003 14:10:24 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hAUMAOKp083128; Sun, 30 Nov 2003 14:10:24 -0800 (PST) (envelope-from gnats) Date: Sun, 30 Nov 2003 14:10:24 -0800 (PST) Message-Id: <200311302210.hAUMAOKp083128@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: David Schultz Subject: Re: standards/59797: Implement C99's round[f]() math fucntions X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Schultz List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2003 22:10:25 -0000 The following reply was made to PR standards/59797; it has been noted by GNATS. From: David Schultz To: "Steven G. Kargl" Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: standards/59797: Implement C99's round[f]() math fucntions Date: Sun, 30 Nov 2003 13:58:00 -0800 On Sat, Nov 29, 2003, Steven G. Kargl wrote: > The enclose diff contains an implementation of the round() and > roundf() math functions found in C99. This is C language > implementation and a MD implementation may be preferred, but it > appears to at least supply the missing functionality. Cool. I'll look into committing this after the freeze. You wouldn't feel up to taking care of roundl() too, would you? This unfortunately requires writing ceill() or modfl(), which is tricky because long double representation is somewhat machine dependent... From owner-freebsd-standards@FreeBSD.ORG Sun Nov 30 15:30:24 2003 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5090516A4CF for ; Sun, 30 Nov 2003 15:30:24 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93B1643F75 for ; Sun, 30 Nov 2003 15:30:23 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hAUNUNFY090321 for ; Sun, 30 Nov 2003 15:30:23 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hAUNUNkD090320; Sun, 30 Nov 2003 15:30:23 -0800 (PST) (envelope-from gnats) Date: Sun, 30 Nov 2003 15:30:23 -0800 (PST) Message-Id: <200311302330.hAUNUNkD090320@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: "Steven G. Kargl" Subject: Re: standards/59797: Implement C99's round[f]() math fucntions X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Steven G. Kargl" List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2003 23:30:24 -0000 The following reply was made to PR standards/59797; it has been noted by GNATS. From: "Steven G. Kargl" To: Stefan Farfeleder Cc: bug-followup@FreeBSD.org Subject: Re: standards/59797: Implement C99's round[f]() math fucntions Date: Sun, 30 Nov 2003 15:21:22 -0800 (PST) Stefan Farfeleder wrote: > On Sat, Nov 29, 2003 at 10:06:27AM -0800, Steven G. Kargl wrote: > > +double round(double x) { > > + double t; > > + if (x >= 0.0) { > > + t = ceil(x); > > + if (t - x > 0.5) t -= 1.0; > > + return t; > > + } else { > > + t = ceil(-x); > > + if (t + x > 0.5) t -= 1.0; > > + return -t; > > + } > > +} > > One suggestion: Could you make that > > +double > +round(double x) > +{ > > to match style(9) and (most of) msun/src/*.c? > I'll submit a style(9) clean-up if the current diff is committed. If you look through msun, you'll see all sorts of sytle(9) violations. -- Steve http://troutmask.apl.washington.edu/~kargl/ From owner-freebsd-standards@FreeBSD.ORG Sun Nov 30 15:30:29 2003 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AB1616A4CF for ; Sun, 30 Nov 2003 15:30:29 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA8F843FBF for ; Sun, 30 Nov 2003 15:30:28 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hAUNUSFY090348 for ; Sun, 30 Nov 2003 15:30:28 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hAUNUSXZ090347; Sun, 30 Nov 2003 15:30:28 -0800 (PST) (envelope-from gnats) Date: Sun, 30 Nov 2003 15:30:28 -0800 (PST) Message-Id: <200311302330.hAUNUSXZ090347@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: "Steven G. Kargl" Subject: Re: standards/59797: Implement C99's round[f]() math fucntions X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Steven G. Kargl" List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2003 23:30:29 -0000 The following reply was made to PR standards/59797; it has been noted by GNATS. From: "Steven G. Kargl" To: David Schultz Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: standards/59797: Implement C99's round[f]() math fucntions Date: Sun, 30 Nov 2003 15:24:27 -0800 (PST) David Schultz wrote: > On Sat, Nov 29, 2003, Steven G. Kargl wrote: > > The enclose diff contains an implementation of the round() and > > roundf() math functions found in C99. This is C language > > implementation and a MD implementation may be preferred, but it > > appears to at least supply the missing functionality. > > Cool. I'll look into committing this after the freeze. > > You wouldn't feel up to taking care of roundl() too, would you? roundl() will be trivial if we have ceill(). > This unfortunately requires writing ceill() or modfl(), which is > tricky because long double representation is somewhat machine > dependent... I'll need to understand the bit twiddling in ceil() before I can tackle ceill(). -- Steve http://troutmask.apl.washington.edu/~kargl/ From owner-freebsd-standards@FreeBSD.ORG Sun Nov 30 15:53:30 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 4628416A4CE for ; Sun, 30 Nov 2003 15:53:30 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C44443F75 for ; Sun, 30 Nov 2003 15:53:29 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) hAUNrT8u044500 for ; Sun, 30 Nov 2003 15:53:29 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)hAUNrSRV044499 for freebsd-standards@FreeBSD.ORG; Sun, 30 Nov 2003 15:53:28 -0800 (PST) (envelope-from sgk) Date: Sun, 30 Nov 2003 15:53:28 -0800 From: Steve Kargl To: freebsd-standards@FreeBSD.ORG Message-ID: <20031130235328.GA44393@troutmask.apl.washington.edu> References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129080911.GA25448@VARK.homeunix.com> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031130213951.GA37082@VARK.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031130213951.GA37082@VARK.homeunix.com> User-Agent: Mutt/1.4.1i Subject: Re: Implementing C99's roundf(), round(), and roundl() 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: Sun, 30 Nov 2003 23:53:30 -0000 On Sun, Nov 30, 2003 at 01:39:51PM -0800, David Schultz wrote: > On Sat, Nov 29, 2003, Steve Kargl wrote: > > > > As a side comment, we need to start coding the missing C99 math(3) > > functions because GCC is moving to using these in their CVS > > development trees. > > Really? Which ones? I don't think I'll have time to deal with > this until January, but then again, we're not doing another gcc > import before then. The tree-ssa branch of GCC contains the new front end for Fortran 95. The runtime library uses round[f](), which is why I wrote the C implementation I submitted. The tree-ssa branch is slated to become gcc-3.5. -- Steve From owner-freebsd-standards@FreeBSD.ORG Sun Nov 30 16:07:02 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 34EF216A4CE for ; Sun, 30 Nov 2003 16:07:02 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49CAA43FCB for ; Sun, 30 Nov 2003 16:07:00 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id hB106xEG020385 for ; Sun, 30 Nov 2003 16:06:59 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10) with ESMTP id hB106xWx048220 for ; Sun, 30 Nov 2003 16:06:59 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10/Submit) id hB106xfP048219 for standards@FreeBSD.org; Sun, 30 Nov 2003 16:06:59 -0800 (PST) (envelope-from marcel) Date: Sun, 30 Nov 2003 16:06:59 -0800 From: Marcel Moolenaar To: standards@FreeBSD.org Message-ID: <20031201000659.GA48096@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: 64-bit NULL: please review patch 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: Mon, 01 Dec 2003 00:07:02 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ok, Attached a patch to help us out in the various ways we may want or need to define NULL. First and foremost, it centralizes the definition so that we don't have to modify a dozen headers to make a change. Secondly, it defines NULL as 0L on ia64 when compiling for the LP64 runtime. When adding -milp32 to gcc (not yet supported), __LP64__ is not defined and NULL will be defined as 0. This is the correct behaviour. With the definition of NULL in a seperate header we can also utilize compiler built-in definitions for NULL is such exist or define NULL specially for lint or other conditions. Please review, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ia64.diff" Index: include/dirent.h =========================================================================== --- include/dirent.h 2003/11/30 14:58:52 #4 +++ include/dirent.h 2003/11/30 14:58:52 @@ -54,6 +54,8 @@ #if __BSD_VISIBLE +#include + /* definitions for library routines operating on directories. */ #define DIRBLKSIZ 1024 @@ -81,10 +83,6 @@ #define DTF_REWIND 0x0004 /* rewind after reading union stack */ #define __DTF_READALL 0x0008 /* everything has been read */ -#ifndef NULL -#define NULL 0 -#endif - #else /* !__BSD_VISIBLE */ typedef void * DIR; Index: include/locale.h =========================================================================== --- include/locale.h 2003/11/30 14:58:52 #3 +++ include/locale.h 2003/11/30 14:58:52 @@ -37,6 +37,8 @@ #ifndef _LOCALE_H_ #define _LOCALE_H_ +#include + struct lconv { char *decimal_point; char *thousands_sep; @@ -64,10 +66,6 @@ char int_n_sign_posn; }; -#ifndef NULL -#define NULL 0 -#endif - #define LC_ALL 0 #define LC_COLLATE 1 #define LC_CTYPE 2 Index: include/rpc/types.h =========================================================================== --- include/rpc/types.h 2003/11/30 14:58:52 #1 +++ include/rpc/types.h 2003/11/30 14:58:52 @@ -40,6 +40,7 @@ #define _RPC_TYPES_H #include +#include typedef int32_t bool_t; typedef int32_t enum_t; @@ -59,9 +60,6 @@ #ifndef TRUE # define TRUE (1) #endif -#ifndef NULL -# define NULL 0 -#endif #define mem_alloc(bsize) calloc(1, bsize) #define mem_free(ptr, bsize) free(ptr) Index: include/stddef.h =========================================================================== --- include/stddef.h 2003/11/30 14:58:52 #5 +++ include/stddef.h 2003/11/30 14:58:52 @@ -39,6 +39,7 @@ #define _STDDEF_H_ #include +#include #include typedef __ptrdiff_t ptrdiff_t; @@ -62,10 +63,6 @@ #endif #endif -#ifndef NULL -#define NULL 0 -#endif - #define offsetof(type, member) __offsetof(type, member) #endif /* _STDDEF_H_ */ Index: include/stdio.h =========================================================================== --- include/stdio.h 2003/11/30 14:58:52 #17 +++ include/stdio.h 2003/11/30 14:58:52 @@ -41,6 +41,7 @@ #define _STDIO_H_ #include +#include #include typedef __off_t fpos_t; @@ -57,10 +58,6 @@ #endif #endif -#ifndef NULL -#define NULL 0 -#endif - #define _FSTDIO /* Define for new stdio with functions. */ /* Index: include/stdlib.h =========================================================================== --- include/stdlib.h 2003/11/30 14:58:52 #32 +++ include/stdlib.h 2003/11/30 14:58:52 @@ -38,6 +38,7 @@ #define _STDLIB_H_ #include +#include #include #if __BSD_VISIBLE @@ -69,10 +70,6 @@ long rem; } ldiv_t; -#ifndef NULL -#define NULL 0 -#endif - #define EXIT_FAILURE 1 #define EXIT_SUCCESS 0 Index: include/string.h =========================================================================== --- include/string.h 2003/11/30 14:58:52 #13 +++ include/string.h 2003/11/30 14:58:52 @@ -38,6 +38,7 @@ #define _STRING_H_ #include +#include #include /* @@ -53,10 +54,6 @@ #define _SIZE_T_DECLARED #endif -#ifndef NULL -#define NULL 0 -#endif - __BEGIN_DECLS #if __POSIX_VISIBLE >= 200112 || __XSI_VISIBLE void *memccpy(void * __restrict, const void * __restrict, int, size_t); Index: include/time.h =========================================================================== --- include/time.h 2003/11/30 14:58:52 #14 +++ include/time.h 2003/11/30 14:58:52 @@ -46,6 +46,7 @@ #define _TIME_H_ #include +#include #include #if __POSIX_VISIBLE > 0 && __POSIX_VISIBLE < 200112 || __BSD_VISIBLE @@ -59,10 +60,6 @@ /* Frequency of the clock ticks reported by clock(). */ #define CLOCKS_PER_SEC 128 -#ifndef NULL -#define NULL 0 -#endif - #ifndef _CLOCK_T_DECLARED typedef __clock_t clock_t; #define _CLOCK_T_DECLARED Index: include/unistd.h =========================================================================== --- include/unistd.h 2003/11/30 14:58:52 #28 +++ include/unistd.h 2003/11/30 14:58:52 @@ -40,6 +40,7 @@ #include #include /* XXX adds too much pollution. */ #include +#include #include #ifndef _GID_T_DECLARED @@ -81,10 +82,6 @@ #define STDOUT_FILENO 1 /* standard output file descriptor */ #define STDERR_FILENO 2 /* standard error file descriptor */ -#ifndef NULL -#define NULL 0 /* null pointer constant */ -#endif - #if __XSI_VISIBLE || __POSIX_VISIBLE >= 200112 #define F_ULOCK 0 /* unlock locked section */ #define F_LOCK 1 /* lock a section for exclusive use */ Index: include/wchar.h =========================================================================== --- include/wchar.h 2003/11/30 14:58:52 #32 +++ include/wchar.h 2003/11/30 14:58:52 @@ -68,13 +68,10 @@ #define _WCHAR_H_ #include +#include #include #include -#ifndef NULL -#define NULL 0 -#endif - #ifndef _MBSTATE_T_DECLARED typedef __mbstate_t mbstate_t; #define _MBSTATE_T_DECLARED Index: sys/sys/_null.h =========================================================================== *** /dev/null Sun Nov 30 14:55:39 2003 --- sys/sys/_null.h Sun Nov 30 14:59:01 2003 *************** *** 0 **** --- 1,37 ---- + /* + * Copyright (c) 2003 Marcel Moolenaar + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + + #ifndef NULL + + #ifdef __LP64__ + #define NULL 0L + #else + #define NULL 0 + #endif + + #endif Index: sys/sys/param.h =========================================================================== --- sys/sys/param.h 2003/11/30 14:58:52 #78 +++ sys/sys/param.h 2003/11/30 14:58:52 @@ -42,6 +42,8 @@ #ifndef _SYS_PARAM_H_ #define _SYS_PARAM_H_ +#include + #define BSD 199506 /* System version (year & month). */ #define BSD4_3 1 #define BSD4_4 1 @@ -59,10 +61,6 @@ #undef __FreeBSD_version #define __FreeBSD_version 501114 /* Master, propagated to newvers */ -#ifndef NULL -#define NULL 0 -#endif - #ifndef LOCORE #include #endif Index: sys/sys/stddef.h =========================================================================== --- sys/sys/stddef.h 2003/11/30 14:58:52 #1 +++ sys/sys/stddef.h 2003/11/30 14:58:52 @@ -30,14 +30,11 @@ #define _SYS_STDDEF_H_ #include +#include #include typedef __ptrdiff_t ptrdiff_t; #define offsetof(type, field) __offsetof(type, field) -#ifndef NULL -#define NULL 0 -#endif - #endif /* !_SYS_STDDEF_H_ */ --envbJBWh7q8WU6mo-- From owner-freebsd-standards@FreeBSD.ORG Sun Nov 30 22:42:13 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 1AB0316A4CF for ; Sun, 30 Nov 2003 22:42:13 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C8B443FBD for ; Sun, 30 Nov 2003 22:42:11 -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 RAA21543; Mon, 1 Dec 2003 17:42:03 +1100 Date: Mon, 1 Dec 2003 17:42:02 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Steven G. Kargl" In-Reply-To: <200311302330.hAUNUNkD090320@freefall.freebsd.org> Message-ID: <20031201173943.A4239@gamplex.bde.org> References: <200311302330.hAUNUNkD090320@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-standards@freebsd.org Subject: Re: standards/59797: Implement C99's round[f]() math fucntions 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: Mon, 01 Dec 2003 06:42:13 -0000 On Sun, 30 Nov 2003, Steven G. Kargl wrote: > Stefan Farfeleder wrote: > > One suggestion: Could you make that > > > > +double > > +round(double x) > > +{ > > > > to match style(9) and (most of) msun/src/*.c? > > I'll submit a style(9) clean-up if the current > diff is committed. If you look through msun, > you'll see all sorts of sytle(9) violations. That's because msun is not written in KNF. Conformance to KNF would be style(9) non-conformance, since the meta rule about using the same style as the existing code has precedence. Bruce From owner-freebsd-standards@FreeBSD.ORG Mon Dec 1 00:05:25 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 33F7216A4CE; Mon, 1 Dec 2003 00:05:25 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2630B43F93; Mon, 1 Dec 2003 00:05:22 -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 TAA09987; Mon, 1 Dec 2003 19:05:18 +1100 Date: Mon, 1 Dec 2003 19:05:18 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Schultz In-Reply-To: <20031130213951.GA37082@VARK.homeunix.com> Message-ID: <20031201182219.O4431@gamplex.bde.org> References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031130213951.GA37082@VARK.homeunix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-standards@freebsd.org cc: Steve Kargl Subject: Re: Implementing C99's roundf(), round(), and roundl() 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: Mon, 01 Dec 2003 08:05:25 -0000 On Sun, 30 Nov 2003, David Schultz wrote: > On Sat, Nov 29, 2003, Steve Kargl wrote: > > On Sat, Nov 29, 2003 at 12:09:11AM -0800, David Schultz wrote: > > > On Fri, Nov 28, 2003, Steve Kargl wrote: > > > > Can the math functions round[fl]() be implemented in > > > > terms of other math(3) functions and still conform to the > > > > C99 and POSIX standard? For example, > > > > [code moved later] > > > > > > This looks correct to me at first glance, modulo possible problems > > > with overflow. ... > > > > I don't undrestand your overflow comment. ceil[f]() can return Inf > > and nan, but in those cases round[f]() should also return Inf and nan. > > The two operations, (t-x) and (t+x), should yield a value in the > > range [0,1). I'll submit a PR with a man page. > > The concern was that ceil() could round a number up to infinity > when round() is supposed to round the number down. But now that I > think about it at a reasonable hour, this concern is clearly > bogus. In base two floating point representations, there isn't > enough precision to get numbers that large with nonzero fractional > parts. It's not completely obvious. I thought of it soon but wondered if I thought of all the cases. Steve's remark about Infs and NaNs points to possible problems: > > > > #include > > > > > > > > float roundf(float x) { > > > > float t; > > > > if (x >= 0.0) { Suppose x is a NaN. Then it will compare strangely with everything and we won't get here. > > > > t = ceilf(x); > > > > if ((t - x) > 0.5) t -= 1.0; > > > > return t; > > > > } else { We get here for NaNs. > > > > t = ceilf(-x); And we really shouldn't do arithmetic on the NaNs. ceilf() should return its arg for a NaN, but it's not clear what happens for -x. Well, I checked what happens starting with the QNaN x= 0.0 / 0.0. Almost everything is broken: - gcc miscomputes 0.0 / 0.0 at compile time. It gives a positive NaN, but the npx would give a negative NaN ("Real Indefinite" = the same one except with the opposite sign). - gcc invalidly optimizes -x by ORing in the sign bit (even without -O). It should do the same as the npx (which is to not change anything). - printf() doesn't print the sign bit for NaNs. - C99 requires printf() to misspell "NaN" as "nan" > > > > if ((t + x) > 0.5) t -= 1.0; > > > > return -t; Now if x is NaN, t is NaN and we do lots of arithmetic on it. I think gcc's invalild optimizations cancel out so NaNs will be returned unchanged. This is not clear :-). > > > > } > > > > } All the other corner cases need to be checked. It's possibly to check all 2^32 cases for floats (once you know the correct results). Other things to check: setting of exception flags. I'm not sure if the settings by ceil() are the right ones and the only ones. Bruce From owner-freebsd-standards@FreeBSD.ORG Mon Dec 1 00:54:29 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 06A4016A4CE for ; Mon, 1 Dec 2003 00:54:29 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-121-163-164.dsl.pltn13.pacbell.net [68.121.163.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9383243FD7 for ; Mon, 1 Dec 2003 00:54:26 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.9/8.12.9) with ESMTP id hB18pten074675; Mon, 1 Dec 2003 00:51:55 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.9/8.12.9/Submit) id hB18psWn074674; Mon, 1 Dec 2003 00:51:54 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Mon, 1 Dec 2003 00:51:54 -0800 From: David Schultz To: Bruce Evans Message-ID: <20031201085154.GA74618@VARK.homeunix.com> Mail-Followup-To: Bruce Evans , Steve Kargl , freebsd-standards@FreeBSD.ORG References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129080911.GA25448@VARK.homeunix.com> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031130213951.GA37082@VARK.homeunix.com> <20031201182219.O4431@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031201182219.O4431@gamplex.bde.org> cc: freebsd-standards@FreeBSD.ORG cc: Steve Kargl Subject: Re: Implementing C99's roundf(), round(), and roundl() 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: Mon, 01 Dec 2003 08:54:29 -0000 On Mon, Dec 01, 2003, Bruce Evans wrote: > And we really shouldn't do arithmetic on the NaNs. ceilf() should return > its arg for a NaN, but it's not clear what happens for -x. Well, I checked > what happens starting with the QNaN x= 0.0 / 0.0. Almost everything is > broken: > - gcc miscomputes 0.0 / 0.0 at compile time. It gives a positive NaN, but > the npx would give a negative NaN ("Real Indefinite" = the same one except > with the opposite sign). > - gcc invalidly optimizes -x by ORing in the sign bit (even without -O). > It should do the same as the npx (which is to not change anything). > - printf() doesn't print the sign bit for NaNs. > - C99 requires printf() to misspell "NaN" as "nan" I thought about that, but I didn't know that the distinction between positive and negative NaN mattered to anyone. If you ignore these distinctions, then any amount of arithmetic on a NaN does nothing, save the possibility of raising an exception. In this case, swapping the sense of the 'if' ought to fix the problem, although an isnan() check could be added instead to be on the safe side. > All the other corner cases need to be checked. It's possibly to check > all 2^32 cases for floats (once you know the correct results). If I had a better way to compute the correct results, I'd commit that instead. ;-P (Okay, actually, I could just use the npx.) > Other things to check: setting of exception flags. I'm not sure if the > settings by ceil() are the right ones and the only ones. What little POSIX says about flags seems to be identical for ceil() and round(). From owner-freebsd-standards@FreeBSD.ORG Mon Dec 1 11:03:38 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 BB7F216A4CE for ; Mon, 1 Dec 2003 11:03:38 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CCF24400D for ; Mon, 1 Dec 2003 11:01:35 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hB1J1ZFY015846 for ; Mon, 1 Dec 2003 11:01:35 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hB1J1ZsG015840 for freebsd-standards@freebsd.org; Mon, 1 Dec 2003 11:01:35 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 Dec 2003 11:01:35 -0800 (PST) Message-Id: <200312011901.hB1J1ZsG015840@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Subject: Current problem reports assigned to you 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: Mon, 01 Dec 2003 19:03:38 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2001/01/23] misc/24590 standards timezone function not compatible witn Sin o [2002/02/25] bin/35307 standards standard include files are not standard c o [2003/03/05] bin/48958 standards The type 'bool' has different sizes for C o [2003/04/21] standards/51209standards [PATCH] add a64l()/l64a/l64a_r functions p [2003/06/05] standards/52972standards /bin/sh arithmetic not POSIX compliant o [2003/06/20] standards/53554standards interval timers not cleared in fork() o [2003/07/12] standards/54410standards one-true-awk not POSIX compliant (no exte o [2003/09/15] standards/56906standards Several math(3) functions fail to set err 8 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/01/16] bin/24390 standards Replacing old dir-symlinks when using /bi o [2001/11/20] standards/32126standards getopt(3) not Unix-98 conformant s [2002/03/18] standards/36076standards Implementation of POSIX fuser command o [2002/06/13] standards/39256standards [v]snprintf aren't POSIX-conformant for s o [2002/07/09] misc/40378 standards stdlib.h gives needless warnings with -an p [2002/08/12] standards/41576standards POSIX compliance of ln(1) o [2002/10/23] standards/44425standards getcwd() succeeds even if current dir has o [2002/12/09] standards/46119standards Priority problems for SCHED_OTHER using p o [2002/12/23] standards/46504standards Warnings in headers o [2003/04/22] standards/51292standards [PATCH] add ecvt()/fcvt()/gcvt() function o [2003/06/22] standards/53613standards FreeBSD doesn't define EPROTO o [2003/06/24] bin/53682 standards [PATCH] add fuser(1) utitity o [2003/07/24] standards/54809standards pcvt deficits o [2003/07/24] standards/54833standards more pcvt deficits o [2003/07/25] standards/54839standards pcvt deficits o [2003/09/04] standards/56476standards cd9660 unicode support simple hack o [2003/09/27] standards/57295standards [patch] make does not include cmd line va o [2003/10/12] standards/57911standards fnmatch ("[[:alpha:]]","x", FNM_PATHNAME) o [2003/10/29] standards/58676standards grantpt(3) alters storage used by ptsname o [2003/11/29] standards/59797standards Implement C99's round[f]() math fucntions 20 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Dec 1 11:05:15 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 D84C816A4D4 for ; Mon, 1 Dec 2003 11:05:15 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A896444048 for ; Mon, 1 Dec 2003 11:03:29 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hB1J3TFY018167 for ; Mon, 1 Dec 2003 11:03:29 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hB1J3S1t018149 for standards@freebsd.org; Mon, 1 Dec 2003 11:03:28 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 Dec 2003 11:03:28 -0800 (PST) Message-Id: <200312011903.hB1J3S1t018149@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: standards@FreeBSD.org Subject: Current problem reports assigned to you 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: Mon, 01 Dec 2003 19:05:16 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/08/18] kern/29844 standards [PATCH] setpgrp does not behave as manual 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/03/05] bin/25542 standards /bin/sh: null char in quoted string 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [1995/01/11] i386/105 standards Distributed libm (msun) has non-standard o [2000/09/24] bin/21519 standards sys/dir.h should be deprecated some more o [2000/12/05] kern/23304 standards POSIX clock_gettime, clock_getres return s [2001/06/18] kern/28260 standards UIO_MAXIOV needs to be made public 4 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Dec 1 12:35: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 BB4BB16A4E8; Mon, 1 Dec 2003 12:35:47 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E82744014; Mon, 1 Dec 2003 12:35:14 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) hB1KZD8u095616; Mon, 1 Dec 2003 12:35:13 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)hB1KZC4D095615; Mon, 1 Dec 2003 12:35:12 -0800 (PST) (envelope-from sgk) Date: Mon, 1 Dec 2003 12:35:12 -0800 From: Steve Kargl To: Bruce Evans Message-ID: <20031201203512.GA95524@troutmask.apl.washington.edu> References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129080911.GA25448@VARK.homeunix.com> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031130213951.GA37082@VARK.homeunix.com> <20031201182219.O4431@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031201182219.O4431@gamplex.bde.org> User-Agent: Mutt/1.4.1i cc: David Schultz cc: freebsd-standards@freebsd.org Subject: Re: Implementing C99's roundf(), round(), and roundl() 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: Mon, 01 Dec 2003 20:35:48 -0000 On Mon, Dec 01, 2003 at 07:05:18PM +1100, Bruce Evans wrote: > On Sun, 30 Nov 2003, David Schultz wrote: > > > On Sat, Nov 29, 2003, Steve Kargl wrote: > > > On Sat, Nov 29, 2003 at 12:09:11AM -0800, David Schultz wrote: > > > > On Fri, Nov 28, 2003, Steve Kargl wrote: > > > > > Can the math functions round[fl]() be implemented in > > > > > terms of other math(3) functions and still conform to the > > > > > C99 and POSIX standard? For example, > > > > > [code moved later] > > > > > > > > This looks correct to me at first glance, modulo possible problems > > > > with overflow. ... > > > > > > I don't undrestand your overflow comment. ceil[f]() can return Inf > > > and nan, but in those cases round[f]() should also return Inf and nan. > > > The two operations, (t-x) and (t+x), should yield a value in the > > > range [0,1). I'll submit a PR with a man page. > > > > The concern was that ceil() could round a number up to infinity > > when round() is supposed to round the number down. But now that I > > think about it at a reasonable hour, this concern is clearly > > bogus. In base two floating point representations, there isn't > > enough precision to get numbers that large with nonzero fractional > > parts. > > It's not completely obvious. I thought of it soon but wondered if I > thought of all the cases. Steve's remark about Infs and NaNs points > to possible problems: > > > > > > #include > > > > > > > > > > float roundf(float x) { > > > > > float t; > > > > > if (x >= 0.0) { > > Suppose x is a NaN. Then it will compare strangely with everything and > we won't get here. I must admit I never thought about the case where round() is called with a NaN as its argument. I just checked the on-line POSIX SUSv3 documents and found: Upon successful completion, these functions shall return the rounded integer value. [MX] If x is NaN, a NaN shall be returned. If x is +-0 or +-Inf, x shall be returned. [XSI] If the correct value would cause overflow, a range error shall occur and round(), roundf(), and roundl() shall return the value of the macro +-HUGE_VAL, +-HUGE_VALF, and +-HUGE_VALL (with the same sign as x), respectively. I, of course, did not check for these special values. > All the other corner cases need to be checked. It's possibly to check > all 2^32 cases for floats (once you know the correct results). Do you have code to do this check? > Other things to check: setting of exception flags. I'm not sure if the > settings by ceil() are the right ones and the only ones. AFAICT, we can't do the exception handling according to POSIX, because we don't have , feclearexcept(), and fetestexcept() implemented, yet. -- Steve From owner-freebsd-standards@FreeBSD.ORG Mon Dec 1 14:57:42 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 4B55216A4CE; Mon, 1 Dec 2003 14:57:42 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13E3243F85; Mon, 1 Dec 2003 14:57:40 -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 JAA00601; Tue, 2 Dec 2003 09:57:33 +1100 Date: Tue, 2 Dec 2003 09:57:33 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Steve Kargl In-Reply-To: <20031201203512.GA95524@troutmask.apl.washington.edu> Message-ID: <20031202091936.I8778@gamplex.bde.org> References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031201182219.O4431@gamplex.bde.org> <20031201203512.GA95524@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Schultz cc: freebsd-standards@freebsd.org Subject: Re: Implementing C99's roundf(), round(), and roundl() 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: Mon, 01 Dec 2003 22:57:42 -0000 On Mon, 1 Dec 2003, Steve Kargl wrote: > On Mon, Dec 01, 2003 at 07:05:18PM +1100, Bruce Evans wrote: > > All the other corner cases need to be checked. It's possibly to check > > all 2^32 cases for floats (once you know the correct results). > > Do you have code to do this check? > > > Other things to check: setting of exception flags. I'm not sure if the > > settings by ceil() are the right ones and the only ones. I thought of a good way after righting the above: roundf() is supposed to be equivalent to rintf() with certain rounding, so set the rounding mode and call rintf() to determine the correct value. Unfortunately there might not be a correct rounding mode (what does round to nearest do for integers? I think it rounds to even, but roundf() requires rounding up half-way cases). > AFAICT, we can't do the exception handling according to POSIX, because > we don't have , feclearexcept(), and fetestexcept() implemented, > yet. RIght, but we have fpgetsticky(), etc. Bruce From owner-freebsd-standards@FreeBSD.ORG Mon Dec 1 19:39:46 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 361F216A4CE; Mon, 1 Dec 2003 19:39:46 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6ECC43FE1; Mon, 1 Dec 2003 19:39:42 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) hB23dg8u098845; Mon, 1 Dec 2003 19:39:42 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)hB23dfT5098844; Mon, 1 Dec 2003 19:39:41 -0800 (PST) (envelope-from sgk) Date: Mon, 1 Dec 2003 19:39:41 -0800 From: Steve Kargl To: Bruce Evans Message-ID: <20031202033941.GA98836@troutmask.apl.washington.edu> References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129080911.GA25448@VARK.homeunix.com> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031130213951.GA37082@VARK.homeunix.com> <20031201182219.O4431@gamplex.bde.org> <20031201203512.GA95524@troutmask.apl.washington.edu> <20031202091936.I8778@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031202091936.I8778@gamplex.bde.org> User-Agent: Mutt/1.4.1i cc: David Schultz cc: freebsd-standards@freebsd.org Subject: Re: Implementing C99's roundf(), round(), and roundl() 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: Tue, 02 Dec 2003 03:39:46 -0000 On Tue, Dec 02, 2003 at 09:57:33AM +1100, Bruce Evans wrote: > On Mon, 1 Dec 2003, Steve Kargl wrote: > > > AFAICT, we can't do the exception handling according to POSIX, because > > we don't have , feclearexcept(), and fetestexcept() implemented, > > yet. > > RIght, but we have fpgetsticky(), etc. > Can we use fpgetsticky() and friends to implement parts of or does this cause some (disallowed) namespace pollution? -- Steve From owner-freebsd-standards@FreeBSD.ORG Mon Dec 1 21:56:51 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 59C2C16A4CE; Mon, 1 Dec 2003 21:56:51 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id D61B043FF7; Mon, 1 Dec 2003 21:56:46 -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 QAA12057; Tue, 2 Dec 2003 16:56:37 +1100 Date: Tue, 2 Dec 2003 16:56:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Steve Kargl In-Reply-To: <20031202033941.GA98836@troutmask.apl.washington.edu> Message-ID: <20031202165346.P10017@gamplex.bde.org> References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031201182219.O4431@gamplex.bde.org> <20031202091936.I8778@gamplex.bde.org> <20031202033941.GA98836@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Schultz cc: freebsd-standards@freebsd.org Subject: Re: Implementing C99's roundf(), round(), and roundl() 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: Tue, 02 Dec 2003 05:56:51 -0000 On Mon, 1 Dec 2003, Steve Kargl wrote: > On Tue, Dec 02, 2003 at 09:57:33AM +1100, Bruce Evans wrote: > > RIght, but we have fpgetsticky(), etc. > > Can we use fpgetsticky() and friends to implement > parts of or does this cause some (disallowed) > namespace pollution? Not quite, and yes. The fp* namespace basically needs to be cloned instead of layered over. Bruce From owner-freebsd-standards@FreeBSD.ORG Thu Dec 4 18:31:56 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 F23BB16A4CE for ; Thu, 4 Dec 2003 18:31:55 -0800 (PST) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7CA843FE5 for ; Thu, 4 Dec 2003 18:31:54 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id hB52Vsuc099262; Thu, 4 Dec 2003 20:31:54 -0600 (CST) (envelope-from dan) Date: Thu, 4 Dec 2003 20:31:53 -0600 From: Dan Nelson To: Garrett Wollman Message-ID: <20031205023153.GC28388@dan.emsphone.com> References: <20031121191529.GD2146@dan.emsphone.com> <200311220440.hAM4eckQ011677@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <200311220440.hAM4eckQ011677@khavrinen.lcs.mit.edu> X-OS: FreeBSD 5.2-BETA X-message-flag: Outlook Error User-Agent: Mutt/1.5.5.1i cc: freebsd-standards@freebsd.org Subject: Re: mktime and tm_isdst 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: Fri, 05 Dec 2003 02:31:56 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In the last episode (Nov 21), Garrett Wollman said: > < said: > > > I've got a question about mktime and FreeBSD's use of the tm_isdst > > flag. > > Suggest you compare with the original code at > and bring up any unresolved issues on > the tz@elsie.nci.nih.gov list. While the two codebases have evolved > in somewhat different directions, the basic implementation should > still be the same (and ours is probably wrong to the extent that it > isn't). It's an interaction with a bug in the original tzcode code and the America/Chicago zone; it doesn't trigger for any other zone afaik. I'd give an url for the patch, but there apparently is no web archive of the list :( Patch attached instead; it's short. -- Dan Nelson dnelson@allantgroup.com --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="localtime.c.diff" Index: localtime.c =================================================================== RCS file: /home/ncvs/src/lib/libc/stdtime/localtime.c,v retrieving revision 1.36 diff -u -r1.36 localtime.c --- localtime.c 16 Feb 2003 17:29:11 -0000 1.36 +++ localtime.c 4 Dec 2003 04:17:11 -0000 @@ -1559,6 +1559,11 @@ time_t t; const struct state * sp; int samei, otheri; + int sameind, otherind; + int i; + int nseen; + int seen[TZ_MAX_TYPES]; + int types[TZ_MAX_TYPES]; int okay; if (tmp->tm_isdst > 1) @@ -1592,10 +1597,20 @@ if (sp == NULL) return WRONG; #endif /* defined ALL_STATE */ - for (samei = sp->typecnt - 1; samei >= 0; --samei) { + for (i = 0; i < sp->typecnt; ++i) + seen[i] = FALSE; + nseen = 0; + for (i = sp->timecnt - 1; i >= 0; --i) + if (!seen[sp->types[i]]) { + seen[sp->types[i]] = TRUE; + types[nseen++] = sp->types[i]; + } + for (sameind = 0; sameind < nseen; ++sameind) { + samei = types[sameind]; if (sp->ttis[samei].tt_isdst != tmp->tm_isdst) continue; - for (otheri = sp->typecnt - 1; otheri >= 0; --otheri) { + for (otherind = 0; otherind < nseen; ++otherind) { + otheri = types[otherind]; if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - --FL5UXtIhxfXey3p5--