From owner-freebsd-standards@FreeBSD.ORG Mon Nov 24 11:02:54 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 2F9A116A4CE for ; Mon, 24 Nov 2003 11:02:54 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92C2E43FA3 for ; Mon, 24 Nov 2003 11:01:36 -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 hAOJ1aFY056251 for ; Mon, 24 Nov 2003 11:01:36 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hAOJ1aGA056245 for freebsd-standards@freebsd.org; Mon, 24 Nov 2003 11:01:36 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 24 Nov 2003 11:01:36 -0800 (PST) Message-Id: <200311241901.hAOJ1aGA056245@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, 24 Nov 2003 19:02:54 -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 19 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Nov 24 11:04:41 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 A79D316A4CE for ; Mon, 24 Nov 2003 11:04:41 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AAA744104 for ; Mon, 24 Nov 2003 11:03:17 -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 hAOJ3HFY058345 for ; Mon, 24 Nov 2003 11:03:17 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hAOJ3Gds058339 for standards@freebsd.org; Mon, 24 Nov 2003 11:03:16 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 24 Nov 2003 11:03:16 -0800 (PST) Message-Id: <200311241903.hAOJ3Gds058339@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, 24 Nov 2003 19:04:41 -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 Tue Nov 25 18:13: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 781E616A4CE for ; Tue, 25 Nov 2003 18:13:23 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84A0443FE0 for ; Tue, 25 Nov 2003 18:13:22 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.9) with ESMTP id hAQ2DLvX056065 for ; Tue, 25 Nov 2003 18:13:22 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.10/8.12.10/Submit) id hAQ2DLRP056064 for freebsd-standards@freebsd.org; Tue, 25 Nov 2003 18:13:21 -0800 (PST) (envelope-from obrien) Date: Tue, 25 Nov 2003 18:13:21 -0800 From: "David O'Brien" To: freebsd-standards@freebsd.org Message-ID: <20031126021321.GA55417@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-BETA Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Subject: Why is max groups set so low (16)? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 02:13:23 -0000 After spending 3 hours debugging Samba problems I found the cause of the problems is that I am >16 groups and our NGROUPS_MAX is set to 16. My question for this group, is why is NGROUPS_MAX set so low? Is it because NFS_MAXGRPS is 16 as specified in some NFS standard? -- -- David (obrien@FreeBSD.org) From owner-freebsd-standards@FreeBSD.ORG Tue Nov 25 18:37:21 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 84C1916A4CE; Tue, 25 Nov 2003 18:37:21 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E0FA43FAF; Tue, 25 Nov 2003 18:37:19 -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 NAA05728; Wed, 26 Nov 2003 13:37:16 +1100 Date: Wed, 26 Nov 2003 13:37:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "David O'Brien" In-Reply-To: <20031126021321.GA55417@dragon.nuxi.com> Message-ID: <20031126132013.E72053@gamplex.bde.org> References: <20031126021321.GA55417@dragon.nuxi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-standards@freebsd.org Subject: Re: Why is max groups set so low (16)? 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, 26 Nov 2003 02:37:21 -0000 On Tue, 25 Nov 2003, David O'Brien wrote: > After spending 3 hours debugging Samba problems I found the cause of the > problems is that I am >16 groups and our NGROUPS_MAX is set to 16. My > question for this group, is why is NGROUPS_MAX set so low? Is it because > NFS_MAXGRPS is 16 as specified in some NFS standard? It is a compile-time constant, so it can't be changed from its historical value without breaking binary compatibility. POSIX specifies only that it be no smaller than _POSIX_NGROUP_MAX (8) if it exists. The binary compatibility problems seem to be small. libc doesn't have any references at all to NGROUPS_MAX except in man pages, but that is partly because it mostly misspells NGROUPS_MAX as NGROUPS. getgroups(2) and setgroups(2) are limited by whatever the kernel wants, not by their API, although their documentation says that there is a compile-time limit (getgroups.2 spells NGROUPS_MAX correctly, but setgroups.2 spells it NGROUPS). Bruce From owner-freebsd-standards@FreeBSD.ORG Fri Nov 28 16:01:35 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 503F616A4CE for ; Fri, 28 Nov 2003 16:01:35 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F33B43F85 for ; Fri, 28 Nov 2003 16:01:34 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) hAT01Y8u030721 for ; Fri, 28 Nov 2003 16:01:34 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)hAT01XUn030720 for freebsd-standards@freebsd.org; Fri, 28 Nov 2003 16:01:34 -0800 (PST) (envelope-from sgk) Date: Fri, 28 Nov 2003 16:01:33 -0800 From: Steve Kargl To: freebsd-standards@freebsd.org Message-ID: <20031129000133.GA30662@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: 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: Sat, 29 Nov 2003 00:01:35 -0000 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; } } -- Steve From owner-freebsd-standards@FreeBSD.ORG Fri Nov 28 16:58:26 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 1E0DF16A4CE for ; Fri, 28 Nov 2003 16:58:26 -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 A90AC43F85 for ; Fri, 28 Nov 2003 16:58:24 -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 hAT0wOEG058581 for ; Fri, 28 Nov 2003 16:58:24 -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 hAT0wNWx020166 for ; Fri, 28 Nov 2003 16:58:23 -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 hAT0wNU7020165 for standards@FreeBSD.org; Fri, 28 Nov 2003 16:58:23 -0800 (PST) (envelope-from marcel) Date: Fri, 28 Nov 2003 16:58:23 -0800 From: Marcel Moolenaar To: standards@FreeBSD.org Message-ID: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: 64-bit NULL: a followup 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: Sat, 29 Nov 2003 00:58:26 -0000 Previously on -standards: On Mon, Oct 27, 2003 at 02:49:51PM +0100, Harti Brandt wrote: > > a question came up wether the NULL should be defined as (0L) on sparc. > (Solaris does this). Currently we define NULL as 0. On Mon, 27 Oct 2003, Erik Trulsson wrote: > > Both are perfectly good definitions of NULL. On Mon, 27 Oct 2003, Tony Finch wrote: > > No, NULL is an implementation-defined null pointer constant, not a null > pointer. The difference is that a null pointer constant is an integer > constant expression that evaluates to zero (optionally cast to void*), > and a null pointer is a null pointer constant converted to a pointer type > (which might involve changes in representation). Therefore using a bare > NULL to terminate the execl argument list is not in general legal. On ia64 I run into a problem where a caller of a function with a variable number of arguments leaves garbage in the high order 32 bits due to the fact that NULL is defined as 0, and thus has type int by default. Take the following simple example: extern int va(int, ...); int foo(void) { return (va(1, 2, 3, 4, 5, 6, 7, 8, NULL)); } The last argument has to be passed onto the stack, which gcc does as follows: : 1c: 01 61 00 84 adds r14=16,r12;; 20: 00 00 00 1c 90 11 [MII] st4 [r14]=r0 26: 40 0a 00 00 48 a0 mov r36=1 2c: 24 00 00 90 mov r37=2 30: 00 30 0d 00 00 24 [MII] mov r38=3 36: 70 22 00 00 48 00 mov r39=4 3c: 55 00 00 90 mov r40=5 40: 00 48 19 00 00 24 [MII] mov r41=6 46: a0 3a 00 00 48 60 mov r42=7 4c: 85 00 00 90 mov r43=8 50: 1c 00 00 00 01 00 [MFB] nop.m 0x0 56: 00 00 00 02 00 00 nop.f 0x0 5c: 08 00 00 50 br.call.sptk.many b0=50 : Notice the "st4". If NULL was defined as 0L, this would look like: : 1c: 01 61 00 84 adds r14=16,r12;; 20: 00 00 00 1c 98 11 [MII] st8 [r14]=r0 26: 40 0a 00 00 48 a0 mov r36=1 : Notice the "st8". Since NULL is a pointer constant, programmers do (implicitly) expect it to have the same width as a pointer type and thus do not cast it to a pointer type or an integer type that has a width larger or equal to a pointer type. So, the bottomline is that we currently do have third-party code that fails to run on ia64 (and possibly other 64-bit platforms) due to the fact that NULL is defined as 0. Since Erik thinks 0 and 0L are both perfectly good definitions for NULL and Tony emphasizes that NULL is an integer expression, I think we should change the definition of NULL to 0L to improve portability to FreeBSD/LP64. It will definitely fix known breakages on ia64. Thoughts? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-standards@FreeBSD.ORG Fri Nov 28 19:19:01 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 17E7916A4CE for ; Fri, 28 Nov 2003 19:19:01 -0800 (PST) Received: from falcon.midgard.homeip.net (h201n1fls24o1048.bredband.comhem.se [212.181.162.201]) by mx1.FreeBSD.org (Postfix) with SMTP id 5CBE043FBD for ; Fri, 28 Nov 2003 19:18:58 -0800 (PST) (envelope-from ertr1013@student.uu.se) Received: (qmail 27764 invoked by uid 1001); 29 Nov 2003 03:18:56 -0000 Date: Sat, 29 Nov 2003 04:18:56 +0100 From: Erik Trulsson To: Marcel Moolenaar Message-ID: <20031129031855.GA27684@falcon.midgard.homeip.net> Mail-Followup-To: Marcel Moolenaar , standards@FreeBSD.org References: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.5.5.1i cc: standards@FreeBSD.org Subject: Re: 64-bit NULL: a followup 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: Sat, 29 Nov 2003 03:19:01 -0000 On Fri, Nov 28, 2003 at 04:58:23PM -0800, Marcel Moolenaar wrote: > Previously on -standards: > > On Mon, Oct 27, 2003 at 02:49:51PM +0100, Harti Brandt wrote: > > > > a question came up wether the NULL should be defined as (0L) on sparc. > > (Solaris does this). Currently we define NULL as 0. > > On Mon, 27 Oct 2003, Erik Trulsson wrote: > > > > Both are perfectly good definitions of NULL. > > On Mon, 27 Oct 2003, Tony Finch wrote: > > > > No, NULL is an implementation-defined null pointer constant, not a null > > pointer. The difference is that a null pointer constant is an integer > > constant expression that evaluates to zero (optionally cast to void*), > > and a null pointer is a null pointer constant converted to a pointer type > > (which might involve changes in representation). Therefore using a bare > > NULL to terminate the execl argument list is not in general legal. > > On ia64 I run into a problem where a caller of a function with a variable > number of arguments leaves garbage in the high order 32 bits due to the > fact that NULL is defined as 0, and thus has type int by default. > > Take the following simple example: > > extern int va(int, ...); > int foo(void) > { > return (va(1, 2, 3, 4, 5, 6, 7, 8, NULL)); > } The last argument needs to be casted to the correct pointer type, for the code to be correct. > > The last argument has to be passed onto the stack, which gcc does > as follows: > > : > 1c: 01 61 00 84 adds r14=16,r12;; > 20: 00 00 00 1c 90 11 [MII] st4 [r14]=r0 > 26: 40 0a 00 00 48 a0 mov r36=1 > 2c: 24 00 00 90 mov r37=2 > 30: 00 30 0d 00 00 24 [MII] mov r38=3 > 36: 70 22 00 00 48 00 mov r39=4 > 3c: 55 00 00 90 mov r40=5 > 40: 00 48 19 00 00 24 [MII] mov r41=6 > 46: a0 3a 00 00 48 60 mov r42=7 > 4c: 85 00 00 90 mov r43=8 > 50: 1c 00 00 00 01 00 [MFB] nop.m 0x0 > 56: 00 00 00 02 00 00 nop.f 0x0 > 5c: 08 00 00 50 br.call.sptk.many b0=50 > : > > Notice the "st4". If NULL was defined as 0L, this would look like: > > : > 1c: 01 61 00 84 adds r14=16,r12;; > 20: 00 00 00 1c 98 11 [MII] st8 [r14]=r0 > 26: 40 0a 00 00 48 a0 mov r36=1 > : > > Notice the "st8". Since NULL is a pointer constant, programmers do > (implicitly) expect it to have the same width as a pointer type and > thus do not cast it to a pointer type or an integer type that has a > width larger or equal to a pointer type. Such an expectation is erroneous. Programmers who have such expectations obviously do not know the C language well enough. When passing NULL as an argument to a function, and when there is not a prototype in scope telling the compiler what type the argument is supposed to have, you must *always* cast it to the correct type. This is the case both for var-arg functions, and for functions with only an old-style declaration/definition in scope. For functions with a prototype in scope, the compiler will automatically convert NULL to the appropriate type. > > So, the bottomline is that we currently do have third-party code that > fails to run on ia64 (and possibly other 64-bit platforms) due to the > fact that NULL is defined as 0. Then that third-party code is buggy, and if the authors of it have made such a basic mistake, then I wouldn't trust the rest of it much either. In a correct C program you it should be possible to just replace any and all occurences of NULL with a plain 0, and the program should continue to work. If it doesn't the program is buggy. > > Since Erik thinks 0 and 0L are both perfectly good definitions for > NULL and Tony emphasizes that NULL is an integer expression, I think > we should change the definition of NULL to 0L to improve portability > to FreeBSD/LP64. It will definitely fix known breakages on ia64. > > Thoughts? You could of course do that, but that would mainly serve to hide bugs in programs. It would be better to get those programs fixed, so that they don't contain such bugs. For that purpose it would be better to continue to have NULL be defined as 0, so that such bugs can be triggered, and thus found, rather than silently ignoring them. Of course, since (0L) is indeed a valid definition of NULL, there is no technical reason why you couldn't make that change. Just be aware that changing the defintion of NULL in this way, does not really fix anything and would most likely trigger bugs in some other programs that make different, equally invalid, assumptions. (Granted, there are most likely fewer programs whos bugs are triggered by NULL being defined as 0L, than when NULL is defined as 0, but there are bound to be some.) -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-standards@FreeBSD.ORG Fri Nov 28 19:42: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 4E64516A4CE for ; Fri, 28 Nov 2003 19:42: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 CE1BC43FEC for ; Fri, 28 Nov 2003 19:41:53 -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 hAT3frEG059327 for ; Fri, 28 Nov 2003 19:41:53 -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 hAT3frWx020718 for ; Fri, 28 Nov 2003 19:41:53 -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 hAT3fr5p020717 for standards@FreeBSD.org; Fri, 28 Nov 2003 19:41:53 -0800 (PST) (envelope-from marcel) Date: Fri, 28 Nov 2003 19:41:52 -0800 From: Marcel Moolenaar To: standards@FreeBSD.org Message-ID: <20031129034152.GA20661@dhcp01.pn.xcllnt.net> References: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> <20031129031855.GA27684@falcon.midgard.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031129031855.GA27684@falcon.midgard.homeip.net> User-Agent: Mutt/1.5.4i Subject: Re: 64-bit NULL: a followup 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: Sat, 29 Nov 2003 03:42:02 -0000 On Sat, Nov 29, 2003 at 04:18:56AM +0100, Erik Trulsson wrote: > > > > Notice the "st8". Since NULL is a pointer constant, programmers do > > (implicitly) expect it to have the same width as a pointer type and > > thus do not cast it to a pointer type or an integer type that has a > > width larger or equal to a pointer type. > > > Such an expectation is erroneous. Programmers who have such > expectations obviously do not know the C language well enough. Fine. So people suck. The problem is that code is written for operating systems that allows them to be ignorant and we'd like that code to run on FreeBSD as well. The programmers you claim of not having enough knowledge about the C language do not care what you think of them and in general do not care much about FreeBSD. Especially if we're going to knock on their doors telling them that they can't program and they need to fix their code because it doesn't work for us. So why not be realistic, come off it and help programmers out? > Of course, since (0L) is indeed a valid definition of NULL, there is no > technical reason why you couldn't make that change. Thanks, this actually is useful information. I do not want to create an invalid definition in support of broken code, but as long as we're within the margins I like to have something that is the most practical (and in my case minimizes the time I need to spend on fixing broken ports). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-standards@FreeBSD.ORG Fri Nov 28 21:39: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 B98A916A4CE for ; Fri, 28 Nov 2003 21:39:23 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 149C743FEA for ; Fri, 28 Nov 2003 21:39: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 QAA19270; Sat, 29 Nov 2003 16:39:14 +1100 Date: Sat, 29 Nov 2003 16:39:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Marcel Moolenaar In-Reply-To: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> Message-ID: <20031129161509.J4841@gamplex.bde.org> References: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@freebsd.org Subject: Re: 64-bit NULL: a followup 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: Sat, 29 Nov 2003 05:39:23 -0000 On Fri, 28 Nov 2003, Marcel Moolenaar wrote: > Notice the "st8". Since NULL is a pointer constant, programmers do > (implicitly) expect it to have the same width as a pointer type and > thus do not cast it to a pointer type or an integer type that has a > width larger or equal to a pointer type. FreeBSD programmers would never do that ;-), since style(9) requires casting of NULL in function args and mentions this point. (This part of style(9) was written before everything in FreeBSD was prototyped, so the cast was required even for non-variadic functions.) > So, the bottomline is that we currently do have third-party code that > fails to run on ia64 (and possibly other 64-bit platforms) due to the > fact that NULL is defined as 0. > > Since Erik thinks 0 and 0L are both perfectly good definitions for > NULL and Tony emphasizes that NULL is an integer expression, I think ^^ may be > we should change the definition of NULL to 0L to improve portability > to FreeBSD/LP64. It will definitely fix known breakages on ia64. This would be bogus. Long doesn't have the same width as `void *' on all machines. ((void *)0) is better, but I wouldn't change it, except locally to trap errors. __builtin_null would be better for trapping errors. Bruce From owner-freebsd-standards@FreeBSD.ORG Fri Nov 28 21:56:21 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 CF3AF16A4CE for ; Fri, 28 Nov 2003 21:56:21 -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 B18D943FBD for ; Fri, 28 Nov 2003 21:56:20 -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 hAT5uKEG006666; Fri, 28 Nov 2003 21:56:20 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) hAT5uJWx052524; Fri, 28 Nov 2003 21:56:20 -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 hAT5uJrL052511; Fri, 28 Nov 2003 21:56:19 -0800 (PST) (envelope-from marcel) Date: Fri, 28 Nov 2003 21:56:19 -0800 From: Marcel Moolenaar To: Bruce Evans Message-ID: <20031129055619.GA48381@dhcp01.pn.xcllnt.net> References: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> <20031129161509.J4841@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031129161509.J4841@gamplex.bde.org> User-Agent: Mutt/1.5.4i cc: standards@freebsd.org Subject: Re: 64-bit NULL: a followup 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: Sat, 29 Nov 2003 05:56:21 -0000 On Sat, Nov 29, 2003 at 04:39:14PM +1100, Bruce Evans wrote: > > > So, the bottomline is that we currently do have third-party code that > > fails to run on ia64 (and possibly other 64-bit platforms) due to the > > fact that NULL is defined as 0. > > > > Since Erik thinks 0 and 0L are both perfectly good definitions for > > NULL and Tony emphasizes that NULL is an integer expression, I think > ^^ may be > > we should change the definition of NULL to 0L to improve portability > > to FreeBSD/LP64. It will definitely fix known breakages on ia64. > > This would be bogus. Long doesn't have the same width as `void *' on all > machines. The bogusness doesn't increase if we're looking at widths. It actually reduces. The FreeBSD runtime is either ILP32 or LP64. Hence, defining NULL as long is better than defining it as int. For those running IP32L64, NULL can trivially be redefined as int. > ((void *)0) is better, but I wouldn't change it, except > locally to trap errors. Ok, so what is better (void*)0 or 0L? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-standards@FreeBSD.ORG Fri Nov 28 22:43:35 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 B693F16A4CE for ; Fri, 28 Nov 2003 22:43:35 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0DEC43FD7 for ; Fri, 28 Nov 2003 22:43:34 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id hAT6hReO003662; Fri, 28 Nov 2003 23:43:27 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Nov 2003 23:43:25 -0700 (MST) Message-Id: <20031128.234325.35797703.imp@bsdimp.com> To: marcel@xcllnt.net From: "M. Warner Losh" In-Reply-To: <20031129055619.GA48381@dhcp01.pn.xcllnt.net> References: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> <20031129161509.J4841@gamplex.bde.org> <20031129055619.GA48381@dhcp01.pn.xcllnt.net> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: standards@freebsd.org Subject: Re: 64-bit NULL: a followup 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: Sat, 29 Nov 2003 06:43:35 -0000 In message: <20031129055619.GA48381@dhcp01.pn.xcllnt.net> Marcel Moolenaar writes: : Ok, so what is better (void*)0 or 0L? Short answer: Yes. "Is it quicker to Philadelphia or by bus?" Longer answer: Each definition helps to flush out certain kinds of bugs while papering over other kinds of bugs. It needs to be 0L for C++, but in C either is fine. I have traditionally had the opposite in my tree than what the current FreeBSD definition is to catch the other kinds of bugs that others don't see with the default definition. Neither one is clearly better or worse than the other in the general case. Warner From owner-freebsd-standards@FreeBSD.ORG Sat Nov 29 00:11:37 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 C9AFB16A4CE for ; Sat, 29 Nov 2003 00:11:37 -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 B77A243F3F for ; Sat, 29 Nov 2003 00:11:36 -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 hAT89Cen025645; Sat, 29 Nov 2003 00:09:12 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.9/8.12.9/Submit) id hAT89CWs025644; Sat, 29 Nov 2003 00:09:12 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Sat, 29 Nov 2003 00:09:11 -0800 From: David Schultz To: Steve Kargl Message-ID: <20031129080911.GA25448@VARK.homeunix.com> Mail-Followup-To: Steve Kargl , freebsd-standards@FreeBSD.ORG References: <20031129000133.GA30662@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031129000133.GA30662@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: Sat, 29 Nov 2003 08:11:37 -0000 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.) From owner-freebsd-standards@FreeBSD.ORG Sat Nov 29 00:19:17 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 DF53816A4CE for ; Sat, 29 Nov 2003 00:19:17 -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 C614D43FAF for ; Sat, 29 Nov 2003 00:19:16 -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 hAT8J5EG007177; Sat, 29 Nov 2003 00:19:05 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) hAT8J4Wx003754; Sat, 29 Nov 2003 00:19:05 -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 hAT8J4o0003753; Sat, 29 Nov 2003 00:19:04 -0800 (PST) (envelope-from marcel) Date: Sat, 29 Nov 2003 00:19:03 -0800 From: Marcel Moolenaar To: "M. Warner Losh" Message-ID: <20031129081903.GA98342@dhcp01.pn.xcllnt.net> References: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> <20031129161509.J4841@gamplex.bde.org> <20031129055619.GA48381@dhcp01.pn.xcllnt.net> <20031128.234325.35797703.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031128.234325.35797703.imp@bsdimp.com> User-Agent: Mutt/1.5.4i cc: standards@freebsd.org Subject: Re: 64-bit NULL: a followup 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: Sat, 29 Nov 2003 08:19:18 -0000 On Fri, Nov 28, 2003 at 11:43:25PM -0700, M. Warner Losh wrote: > In message: <20031129055619.GA48381@dhcp01.pn.xcllnt.net> > Marcel Moolenaar writes: > : Ok, so what is better (void*)0 or 0L? > > ... It needs to be 0L for C++, but in C either is fine. ... Then there's no question that 0L is better, because it doesn't break C++. Elementary... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-standards@FreeBSD.ORG Sat Nov 29 03:54:03 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 0C1AD16A4CE for ; Sat, 29 Nov 2003 03:54:03 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C4B743F93 for ; Sat, 29 Nov 2003 03:54:01 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])hATBrou15308; Sat, 29 Nov 2003 12:53:51 +0100 (MET) Date: Sat, 29 Nov 2003 12:53:49 +0100 (CET) From: Harti Brandt To: Bruce Evans In-Reply-To: <20031129161509.J4841@gamplex.bde.org> Message-ID: <20031129124129.Q46692@beagle.fokus.fraunhofer.de> References: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> <20031129161509.J4841@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@freebsd.org cc: Marcel Moolenaar Subject: Re: 64-bit NULL: a followup 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: Sat, 29 Nov 2003 11:54:03 -0000 On Sat, 29 Nov 2003, Bruce Evans wrote: BE>On Fri, 28 Nov 2003, Marcel Moolenaar wrote: BE> BE>> Notice the "st8". Since NULL is a pointer constant, programmers do BE>> (implicitly) expect it to have the same width as a pointer type and BE>> thus do not cast it to a pointer type or an integer type that has a BE>> width larger or equal to a pointer type. BE> BE>FreeBSD programmers would never do that ;-), since style(9) requires BE>casting of NULL in function args and mentions this point. (This part BE>of style(9) was written before everything in FreeBSD was prototyped, BE>so the cast was required even for non-variadic functions.) A couple of weeks ago I searched the tree for occurences of execl with missing casts. There is still one occurence in our sources. There are several in contrib. I have contact most authors and all of them have fixed it (except the gdb people - no answer from the up to now). Problematic are nvi (the maintainer said he'll fix it, but doesn't know whether there will be another version of nvi) and bind. The bind in our tree isn't maintened anymore by ISC and bind 9 doesn't have execv(). All that said, I think whether we change the definition or not it's always best to contact the original authors. BE> BE>> So, the bottomline is that we currently do have third-party code that BE>> fails to run on ia64 (and possibly other 64-bit platforms) due to the BE>> fact that NULL is defined as 0. BE>> BE>> Since Erik thinks 0 and 0L are both perfectly good definitions for BE>> NULL and Tony emphasizes that NULL is an integer expression, I think BE> ^^ may be BE>> we should change the definition of NULL to 0L to improve portability BE>> to FreeBSD/LP64. It will definitely fix known breakages on ia64. BE> BE>This would be bogus. Long doesn't have the same width as `void *' on all BE>machines. ((void *)0) is better, but I wouldn't change it, except BE>locally to trap errors. __builtin_null would be better for trapping BE>errors. Yes. Best would be if gcc complains when applying a default promotion to __builtin_null. But hacking gcc was a disgusting experience last time I did it (around 2.5 or 2.6). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-standards@FreeBSD.ORG Sat Nov 29 05:40:52 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 2175F16A4CE for ; Sat, 29 Nov 2003 05:40:52 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 285B643FEC for ; Sat, 29 Nov 2003 05:40:50 -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 AAA32381; Sun, 30 Nov 2003 00:40:41 +1100 Date: Sun, 30 Nov 2003 00:40:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Marcel Moolenaar In-Reply-To: <20031129055619.GA48381@dhcp01.pn.xcllnt.net> Message-ID: <20031130003519.M1415@gamplex.bde.org> References: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> <20031129055619.GA48381@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@freebsd.org Subject: Re: 64-bit NULL: a followup 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: Sat, 29 Nov 2003 13:40:52 -0000 On Fri, 28 Nov 2003, Marcel Moolenaar wrote: > On Sat, Nov 29, 2003 at 04:39:14PM +1100, Bruce Evans wrote: > > > Since Erik thinks 0 and 0L are both perfectly good definitions for > > > NULL and Tony emphasizes that NULL is an integer expression, I think > > ^^ may be > > > we should change the definition of NULL to 0L to improve portability > > > to FreeBSD/LP64. It will definitely fix known breakages on ia64. > > > > This would be bogus. Long doesn't have the same width as `void *' on all > > machines. > > The bogusness doesn't increase if we're looking at widths. It actually > reduces. The FreeBSD runtime is either ILP32 or LP64. Hence, defining > NULL as long is better than defining it as int. For those running > IP32L64, NULL can trivially be redefined as int. It could be MD in all cases to hide bugs in a MD way. > > ((void *)0) is better, but I wouldn't change it, except > > locally to trap errors. > > Ok, so what is better (void*)0 or 0L? I thought the former, but forgot about C++. There could be ugly ifdefs for this. Bruce From owner-freebsd-standards@FreeBSD.ORG Sat Nov 29 08:31:07 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 1963716A4CE for ; Sat, 29 Nov 2003 08:31:07 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DA9A43FBF for ; Sat, 29 Nov 2003 08:31:06 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) hATGV58u036014 for ; Sat, 29 Nov 2003 08:31:05 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)hATGV51Z036013 for freebsd-standards@FreeBSD.ORG; Sat, 29 Nov 2003 08:31:05 -0800 (PST) (envelope-from sgk) Date: Sat, 29 Nov 2003 08:31:05 -0800 From: Steve Kargl To: freebsd-standards@FreeBSD.ORG Message-ID: <20031129163105.GA32651@troutmask.apl.washington.edu> References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129080911.GA25448@VARK.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031129080911.GA25448@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: Sat, 29 Nov 2003 16:31:07 -0000 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. 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. -- Steve From owner-freebsd-standards@FreeBSD.ORG Sat Nov 29 09:36:10 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 E166A16A4CE for ; Sat, 29 Nov 2003 09:36:10 -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 B237143FBD for ; Sat, 29 Nov 2003 09:36:09 -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 hATHa9EG012577; Sat, 29 Nov 2003 09:36:09 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) hATHa9Wx040657; Sat, 29 Nov 2003 09:36:09 -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 hATHa8GQ040656; Sat, 29 Nov 2003 09:36:08 -0800 (PST) (envelope-from marcel) Date: Sat, 29 Nov 2003 09:36:08 -0800 From: Marcel Moolenaar To: Bruce Evans Message-ID: <20031129173608.GA40606@dhcp01.pn.xcllnt.net> References: <20031129005823.GA20090@dhcp01.pn.xcllnt.net> <20031129161509.J4841@gamplex.bde.org> <20031129055619.GA48381@dhcp01.pn.xcllnt.net> <20031130003519.M1415@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031130003519.M1415@gamplex.bde.org> User-Agent: Mutt/1.5.4i cc: standards@freebsd.org Subject: Re: 64-bit NULL: a followup 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: Sat, 29 Nov 2003 17:36:11 -0000 On Sun, Nov 30, 2003 at 12:40:41AM +1100, Bruce Evans wrote: > > > > The bogusness doesn't increase if we're looking at widths. It actually > > reduces. The FreeBSD runtime is either ILP32 or LP64. Hence, defining > > NULL as long is better than defining it as int. For those running > > IP32L64, NULL can trivially be redefined as int. > > It could be MD in all cases to hide bugs in a MD way. Yes. This corresponds to MD behaviour of gcc. On alpha, amd64 and sparc64 gcc widens NULL to 64 bit for arguments that have to be passed on the stack (still in the context of variadic functions). On ia64 gcc does not do that. The end result is that the use of NULL (when defined as 0) without cast works for the first 8 arguments, because those are passed in registers, but fail for all subsequent arguments. The widening on the other platforms already hide bugs, but at least create consistent behaviour. On ia64 the behaviour is inconsistent, but AFAICT correct from a standards point of view. Nonetheless utterly bogus behaviour from usability and portability points of view. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-standards@FreeBSD.ORG Sat Nov 29 10:10:22 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 E097816A4CE for ; Sat, 29 Nov 2003 10:10:22 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E73043F75 for ; Sat, 29 Nov 2003 10:10:18 -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 hATIAIFY084965 for ; Sat, 29 Nov 2003 10:10:18 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hATIAIkw084964; Sat, 29 Nov 2003 10:10:18 -0800 (PST) (envelope-from gnats) Resent-Date: Sat, 29 Nov 2003 10:10:18 -0800 (PST) Resent-Message-Id: <200311291810.hATIAIkw084964@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-standards@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Steven G. Kargl" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBB8016A4CE for ; Sat, 29 Nov 2003 10:07:49 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id C95A644037 for ; Sat, 29 Nov 2003 10:06:27 -0800 (PST) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) hATI6R8u036634 for ; Sat, 29 Nov 2003 10:06:27 -0800 (PST) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost)hATI6RTL036633; Sat, 29 Nov 2003 10:06:27 -0800 (PST) (envelope-from kargl) Message-Id: <200311291806.hATI6RTL036633@troutmask.apl.washington.edu> Date: Sat, 29 Nov 2003 10:06:27 -0800 (PST) From: "Steven G. Kargl" To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: 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: Sat, 29 Nov 2003 18:10:23 -0000 >Number: 59797 >Category: standards >Synopsis: Implement C99's round[f]() math fucntions >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat Nov 29 10:10:18 PST 2003 >Closed-Date: >Last-Modified: >Originator: Steven G. Kargl >Release: FreeBSD 5.1-CURRENT i386 >Organization: APL/UW >Environment: System: FreeBSD troutmask.apl.washington.edu 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Thu Sep 18 11:50:56 PDT 2003 >Description: 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. Note, future versions of GCC will require these functions. >How-To-Repeat: >Fix: diff -uNr msun.orig/Makefile msun/Makefile --- msun.orig/Makefile Sat Oct 25 02:32:18 2003 +++ msun/Makefile Sat Nov 29 09:52:42 2003 @@ -84,7 +84,8 @@ s_floor.c s_floorf.c s_frexp.c s_frexpf.c s_ilogb.c s_ilogbf.c \ s_isnanf.c s_ldexpf.c s_lib_version.c s_log1p.c \ s_log1pf.c s_logb.c s_logbf.c s_matherr.c s_modff.c \ - s_nextafter.c s_nextafterf.c s_rint.c s_rintf.c s_scalbn.c s_scalbnf.c \ + s_nextafter.c s_nextafterf.c s_rint.c s_rintf.c s_round.c s_roundf.c \ + s_scalbn.c s_scalbnf.c \ s_signgam.c s_significand.c s_significandf.c s_sin.c s_sinf.c s_tan.c \ s_tanf.c s_tanh.c s_tanhf.c \ w_acos.c w_acosf.c w_acosh.c w_acoshf.c w_asin.c w_asinf.c w_atan2.c \ @@ -121,7 +122,7 @@ MAN= acos.3 acosh.3 asin.3 asinh.3 atan.3 atan2.3 atanh.3 ceil.3 \ cos.3 cosh.3 erf.3 exp.3 fabs.3 floor.3 fmod.3 hypot.3 ieee.3 \ - ieee_test.3 j0.3 lgamma.3 math.3 rint.3 sin.3 sinh.3 sqrt.3 \ + ieee_test.3 j0.3 lgamma.3 math.3 rint.3 round.3 sin.3 sinh.3 sqrt.3 \ tan.3 tanh.3 MLINKS+=acos.3 acosf.3 diff -uNr msun.orig/man/round.3 msun/man/round.3 --- msun.orig/man/round.3 Wed Dec 31 16:00:00 1969 +++ msun/man/round.3 Sat Nov 29 09:52:17 2003 @@ -0,0 +1,63 @@ +.\" Copyright (c) 2003, Steven G. Kargl +.\" 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 REGENTS AND CONTRIBUTORS ``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 REGENTS OR CONTRIBUTORS 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. +.\" +.Dd November 29, 2003 +.Dt ROUND 3 +.Os +.Sh NAME +.Nm round , +.Nm roundf +.Nd nearest integral value; if the argument is halfway between two integral +values then round away from zero +.Sh LIBRARY +.Lb libm +.Sh SYNOPSIS +.In math.h +.Ft double +.Fn round "double x" +.Ft float +.Fn roundf "float x" +.Sh DESCRIPTION +The +.Fn round +and the +.Fn roundf +functions return the nearest integral value to +.Fa x ; +if +.Fa x +lies halfway between two integral values, then these +functions return the integral value with the larger +absolute value (i.e., they round away from zero). +.Sh SEE ALSO +.Xr ceil 3 , +.Xr floor 3 , +.Xr ieee 3 , +.Xr math 3 , +.Xr rint 3 +.Sh STANDARDS +The +.Fn round +function conforms to +.St -isoC-99 . diff -uNr msun.orig/src/math.h msun/src/math.h --- msun.orig/src/math.h Thu Oct 23 01:23:38 2003 +++ msun/src/math.h Sat Nov 29 09:53:48 2003 @@ -191,6 +191,7 @@ double fabs(double); double floor(double); double fmod(double, double); +double round(double); /* * These functions are not in C90 so they can be "right". The ones that @@ -281,6 +282,7 @@ float fabsf(float); float floorf(float); float fmodf(float, float); +float roundf(float); float erff(float); float erfcf(float) __pure2; diff -uNr msun.orig/src/s_round.c msun/src/s_round.c --- msun.orig/src/s_round.c Wed Dec 31 16:00:00 1969 +++ msun/src/s_round.c Sat Nov 29 09:49:01 2003 @@ -0,0 +1,40 @@ +/*- + * Copyright (c) 2003, Steven G. Kargl + * 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 unmodified, 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. + */ + +#include + +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; + } +} diff -uNr msun.orig/src/s_roundf.c msun/src/s_roundf.c --- msun.orig/src/s_roundf.c Wed Dec 31 16:00:00 1969 +++ msun/src/s_roundf.c Sat Nov 29 09:48:56 2003 @@ -0,0 +1,40 @@ +/*- + * Copyright (c) 2003, Steven G. Kargl + * 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 unmodified, 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. + */ + +#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; + } +} >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-standards@FreeBSD.ORG Sat Nov 29 13:23:36 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 29D2D16A4CE; Sat, 29 Nov 2003 13:23:36 -0800 (PST) Received: from host.server-23.net (host.server-23.net [64.191.95.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9E0343FBF; Sat, 29 Nov 2003 13:23:34 -0800 (PST) (envelope-from samy@kerneled.com) Received: from dial37-244.sbm.net.sa ([212.46.37.244] helo=beastie.freebsd.local) by host.server-23.net with asmtp (Exim 4.24) id 1AQCYj-0004PZ-Ek; Sat, 29 Nov 2003 16:23:22 -0500 Date: Sun, 30 Nov 2003 00:23:40 +0300 From: Samy Al Bahra To: Bruce Evans Message-Id: <20031130002340.57e5fb60.samy@kerneled.com> In-Reply-To: <20031126132013.E72053@gamplex.bde.org> References: <20031126021321.GA55417@dragon.nuxi.com> <20031126132013.E72053@gamplex.bde.org> Organization: Kerneled X-Mailer: Sylpheed version 0.9.5-gtk2-20030906 (GTK+ 2.2.1; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.server-23.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - kerneled.com cc: freebsd-standards@freebsd.org cc: obrien@freebsd.org Subject: Re: Why is max groups set so low (16)? 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: Sat, 29 Nov 2003 21:23:36 -0000 On Wed, 26 Nov 2003 13:37:15 +1100 (EST) Bruce Evans wrote: > The binary compatibility problems seem to be small. libc doesn't have > any references at all to NGROUPS_MAX except in man pages, but that is > partly because it mostly misspells NGROUPS_MAX as NGROUPS. This isn't a misspelling, param.h defines the following: #define NGROUPS NGROUPS_MAX /* max number groups */ > getgroups(2) and setgroups(2) are limited by whatever the kernel > wants, not by their API, although their documentation says that there > is a compile-time limit setgroups does not allow a user to be in a a greater number of groups than NGROUPS. It references this macro directly, meaning, it is a compile-time limit. Could you elaborate on what you mean exactly by "whatever the kernel wants"? -- +-----------------------------------+ | Samy Al Bahra | samy@kerneled.com | |-----------------------------------| | B3A7 F5BE B2AE 67B1 AC4B | | 0983 956D 1F4A AA54 47CB | |-----------------------------------| | http://www.kerneled.com | +-----------------------------------+ From owner-freebsd-standards@FreeBSD.ORG Sat Nov 29 15:51:50 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 6487916A4E3 for ; Sat, 29 Nov 2003 15:51:50 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6A7C44008 for ; Sat, 29 Nov 2003 15:50: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 hATNoLFY044622 for ; Sat, 29 Nov 2003 15:50:21 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hATNoLLa044621; Sat, 29 Nov 2003 15:50:21 -0800 (PST) (envelope-from gnats) Date: Sat, 29 Nov 2003 15:50:21 -0800 (PST) Message-Id: <200311292350.hATNoLLa044621@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Stefan Farfeleder 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: Stefan Farfeleder List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2003 23:51:52 -0000 The following reply was made to PR standards/59797; it has been noted by GNATS. From: Stefan Farfeleder To: "Steven G. Kargl" Cc: bug-followup@FreeBSD.org Subject: Re: standards/59797: Implement C99's round[f]() math fucntions Date: Sun, 30 Nov 2003 00:40:04 +0100 On Sat, Nov 29, 2003 at 10:06:27AM -0800, Steven G. Kargl wrote: > >Synopsis: Implement C99's round[f]() math fucntions Nice! > +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? Cheers, Stefan From owner-freebsd-standards@FreeBSD.ORG Sat Nov 29 18:00:37 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 65C0916A4CE; Sat, 29 Nov 2003 18:00:37 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D04443F75; Sat, 29 Nov 2003 18:00:34 -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 NAA05495; Sun, 30 Nov 2003 13:00:26 +1100 Date: Sun, 30 Nov 2003 13:00:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Samy Al Bahra In-Reply-To: <20031130002340.57e5fb60.samy@kerneled.com> Message-ID: <20031130123237.Y3720@gamplex.bde.org> References: <20031126021321.GA55417@dragon.nuxi.com> <20031126132013.E72053@gamplex.bde.org> <20031130002340.57e5fb60.samy@kerneled.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-standards@freebsd.org cc: obrien@freebsd.org Subject: Re: Why is max groups set so low (16)? 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 02:00:37 -0000 On Sun, 30 Nov 2003, Samy Al Bahra wrote: > On Wed, 26 Nov 2003 13:37:15 +1100 (EST) > Bruce Evans wrote: > > > The binary compatibility problems seem to be small. libc doesn't have > > any references at all to NGROUPS_MAX except in man pages, but that is > > partly because it mostly misspells NGROUPS_MAX as NGROUPS. > > This isn't a misspelling, param.h defines the following: > #define NGROUPS NGROUPS_MAX /* max number groups */ I mean that it is an archaice spelling. It is the BSD spelling of NGROUPS_MAX so it should not be used in any code written since the latter was standardized 15 years ago. > > getgroups(2) and setgroups(2) are limited by whatever the kernel > > wants, not by their API, although their documentation says that there > > is a compile-time limit > > setgroups does not allow a user to be in a a greater number of groups > than NGROUPS. It references this macro directly, meaning, it is a > compile-time limit. > > Could you elaborate on what you mean exactly by "whatever the kernel > wants"? setgroups() is in the kernel, so it can easily be compiled using a different value of setgroups(). Applications just need to pass a gidset array with all the groups that they want and it will work provided the kernel supports that many. OTOH, a bad API that required setgroups() to pass a (pointer to a) gidset array of precisely NGROUPS_MAX elements would not work. Similarly for getgroups(). It returns the number of groups that there are, so applications can use dynamic allocation to make the array large enough. However, the guarantee that the number is <= NGROUPS_MAX encourages applications to used fixed-size arrays. Bruce