From owner-freebsd-standards@FreeBSD.ORG Sun Apr 13 04:20:03 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 693A937B42A for ; Sun, 13 Apr 2003 04:20:03 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EB0643FAF for ; Sun, 13 Apr 2003 04:20:03 -0700 (PDT) (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 h3DBK2Up053134 for ; Sun, 13 Apr 2003 04:20:02 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h3DBK2st053133; Sun, 13 Apr 2003 04:20:02 -0700 (PDT) Date: Sun, 13 Apr 2003 04:20:02 -0700 (PDT) Message-Id: <200304131120.h3DBK2st053133@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: "Sergey A. Osokin" Subject: Re: standards/50848: [PATCH] Implementation of pthread_[get|set]concurrency X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Sergey A. Osokin" List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2003 11:20:03 -0000 The following reply was made to PR standards/50848; it has been noted by GNATS. From: "Sergey A. Osokin" To: FreeBSD-gnats-submit@FreeBSD.org Cc: Subject: Re: standards/50848: [PATCH] Implementation of pthread_[get|set]concurrency Date: Sun, 13 Apr 2003 15:18:42 +0400 On Sat, Apr 12, 2003 at 01:40:08AM -0700, FreeBSD-gnats-submit@FreeBSD.org wrote: > >Category: standards > >Responsible: freebsd-standards > >Synopsis: [PATCH] Implementation of pthread_[get|set]concurrency > >Arrival-Date: Sat Apr 12 01:40:07 PDT 2003 I think next version of patch is better... http://ozz.pp.ru/patches/patch-pthread.2 -- Rgdz, /"\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ / AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ From owner-freebsd-standards@FreeBSD.ORG Tue Apr 15 18:10:16 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 B92F837B404 for ; Tue, 15 Apr 2003 18:10:16 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15BE143FB1 for ; Tue, 15 Apr 2003 18:10:16 -0700 (PDT) (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 h3G1AFUp041040 for ; Tue, 15 Apr 2003 18:10:15 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h3G1AFUm041039; Tue, 15 Apr 2003 18:10:15 -0700 (PDT) Date: Tue, 15 Apr 2003 18:10:15 -0700 (PDT) Message-Id: <200304160110.h3G1AFUm041039@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Alexander Kabaev Subject: Re: standards/50523: Deprecate , add X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alexander Kabaev List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 01:10:17 -0000 The following reply was made to PR standards/50523; it has been noted by GNATS. From: Alexander Kabaev To: freebsd-gnats-submit@FreeBSD.org, rodrigc@attbi.com Cc: Subject: Re: standards/50523: Deprecate , add Date: Tue, 15 Apr 2003 21:06:44 -0400 Craig, the patch looks OK, but I think this should be handled through repo-copy so that the history on deprecated files will get lost. -- Alexander Kabaev From owner-freebsd-standards@FreeBSD.ORG Wed Apr 16 04:41:57 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 524B037B401 for ; Wed, 16 Apr 2003 04:41:57 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77D8743FB1 for ; Wed, 16 Apr 2003 04:41:55 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA12671; Wed, 16 Apr 2003 21:41:44 +1000 Date: Wed, 16 Apr 2003 21:41:43 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Alexander Kabaev In-Reply-To: <200304160110.h3G1AFUm041039@freefall.freebsd.org> Message-ID: <20030416214053.Y5329@gamplex.bde.org> References: <200304160110.h3G1AFUm041039@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-standards@freebsd.org Subject: Re: standards/50523: Deprecate , add 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, 16 Apr 2003 11:41:57 -0000 On Tue, 15 Apr 2003, Alexander Kabaev wrote: > the patch looks OK, but I think this should be handled through repo-copy > so that the history on deprecated files will get lost. Not to mention copyrights in them. Bruce From owner-freebsd-standards@FreeBSD.ORG Wed Apr 16 05:49:56 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 CCE1737B401; Wed, 16 Apr 2003 05:49:56 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53D2A43FE1; Wed, 16 Apr 2003 05:49:56 -0700 (PDT) (envelope-from schweikh@FreeBSD.org) Received: from freefall.freebsd.org (schweikh@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h3GCnuUp071051; Wed, 16 Apr 2003 05:49:56 -0700 (PDT) (envelope-from schweikh@freefall.freebsd.org) Received: (from schweikh@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h3GCntqZ071047; Wed, 16 Apr 2003 05:49:55 -0700 (PDT) Date: Wed, 16 Apr 2003 05:49:55 -0700 (PDT) From: Jens Schweikhardt Message-Id: <200304161249.h3GCntqZ071047@freefall.freebsd.org> To: lamer@properfucked.net, schweikh@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: standards/50889: NULL defined as 0 instead of (void *)0 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, 16 Apr 2003 12:49:57 -0000 Synopsis: NULL defined as 0 instead of (void *)0 State-Changed-From-To: open->analyzed State-Changed-By: schweikh State-Changed-When: Wed Apr 16 05:38:52 PDT 2003 State-Changed-Why: The bug is in your code. Because ISO 9899 explicitly allows NULL to be defined as 0 (C99 6.3.2.3), any code must take this possibility into account. If expansion to 0 leads to different semantics than expansion to (void*)0 then the code must use a cast. I agree, though, that it may be desirable to #define NULL ((void*)0) http://www.freebsd.org/cgi/query-pr.cgi?pr=50889 From owner-freebsd-standards@FreeBSD.ORG Wed Apr 16 05:57:20 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 0995B37B401 for ; Wed, 16 Apr 2003 05:57:20 -0700 (PDT) Received: from falcon.midgard.homeip.net (h76n3fls20o913.telia.com [213.67.148.76]) by mx1.FreeBSD.org (Postfix) with SMTP id 6E4D243FB1 for ; Wed, 16 Apr 2003 05:57:17 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: (qmail 12320 invoked by uid 1001); 16 Apr 2003 12:57:15 -0000 Date: Wed, 16 Apr 2003 14:57:15 +0200 From: Erik Trulsson To: Jens Schweikhardt Message-ID: <20030416125715.GA12300@falcon.midgard.homeip.net> Mail-Followup-To: Jens Schweikhardt , lamer@properfucked.net, freebsd-standards@FreeBSD.org References: <200304161249.h3GCntqZ071047@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304161249.h3GCntqZ071047@freefall.freebsd.org> User-Agent: Mutt/1.5.4i cc: freebsd-standards@FreeBSD.org cc: lamer@properfucked.net Subject: Re: standards/50889: NULL defined as 0 instead of (void *)0 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, 16 Apr 2003 12:57:20 -0000 On Wed, Apr 16, 2003 at 05:49:55AM -0700, Jens Schweikhardt wrote: > Synopsis: NULL defined as 0 instead of (void *)0 > > State-Changed-From-To: open->analyzed > State-Changed-By: schweikh > State-Changed-When: Wed Apr 16 05:38:52 PDT 2003 > State-Changed-Why: > The bug is in your code. Because ISO 9899 explicitly allows NULL to be > defined as 0 (C99 6.3.2.3), any code must take this possibility into > account. If expansion to 0 leads to different semantics than expansion > to (void*)0 then the code must use a cast. Correct. > > I agree, though, that it may be desirable to > #define NULL ((void*)0) Unless you want to use the same definition for both C and C++. In C++ the only valid way of defining NULL is #define NULL 0 because in C++ there is no automatic conversion between "pointer to void" and other pointer types as there is in C. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=50889 > _______________________________________________ > freebsd-standards@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-standards > To unsubscribe, send any mail to "freebsd-standards-unsubscribe@freebsd.org" -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-standards@FreeBSD.ORG Wed Apr 16 07:10: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 E591837B409 for ; Wed, 16 Apr 2003 07:10:24 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C58C43F3F for ; Wed, 16 Apr 2003 07:10:24 -0700 (PDT) (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 h3GEAOUp031252 for ; Wed, 16 Apr 2003 07:10:24 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h3GEAOXA031251; Wed, 16 Apr 2003 07:10:24 -0700 (PDT) Date: Wed, 16 Apr 2003 07:10:24 -0700 (PDT) Message-Id: <200304161410.h3GEAOXA031251@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: rodrigc@attbi.com Subject: Re: standards/50523: Deprecate , add X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rodrigc@attbi.com List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 14:10:25 -0000 The following reply was made to PR standards/50523; it has been noted by GNATS. From: rodrigc@attbi.com To: freebsd-gnats-submit@FreeBSD.org, rodrigc@attbi.com Cc: kan@FreeBSD.org Subject: Re: standards/50523: Deprecate , add Date: Wed, 16 Apr 2003 10:07:45 -0400 (EDT) > Craig, > > the patch looks OK, but I think this should be handled through repo-copy > so that the history on deprecated files will get lost. > > -- > Alexander Kabaev Hi, I am not a committer, so do not know how to proceed from here. Is there anyone who is interested in shepherding this patch in? -- Craig Rodrigues rodrigc@attbi.com From owner-freebsd-standards@FreeBSD.ORG Wed Apr 16 08:00: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 354E537B404; Wed, 16 Apr 2003 08:00:56 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9369943F3F; Wed, 16 Apr 2003 08:00:54 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA30383; Thu, 17 Apr 2003 01:00:42 +1000 Date: Thu, 17 Apr 2003 01:00:40 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Erik Trulsson In-Reply-To: <20030416125715.GA12300@falcon.midgard.homeip.net> Message-ID: <20030417005708.D6167@gamplex.bde.org> References: <200304161249.h3GCntqZ071047@freefall.freebsd.org> <20030416125715.GA12300@falcon.midgard.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: lamer@properfucked.net cc: freebsd-standards@freebsd.org cc: Jens Schweikhardt Subject: Re: standards/50889: NULL defined as 0 instead of (void *)0 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, 16 Apr 2003 15:00:56 -0000 On Wed, 16 Apr 2003, Erik Trulsson wrote: > On Wed, Apr 16, 2003 at 05:49:55AM -0700, Jens Schweikhardt wrote: > > I agree, though, that it may be desirable to > > #define NULL ((void*)0) > > Unless you want to use the same definition for both C and C++. > In C++ the only valid way of defining NULL is > > #define NULL 0 > > because in C++ there is no automatic conversion between "pointer to > void" and other pointer types as there is in C. I agree. It may be, and is, also desireable to define NULL as 0. A bit more desireable IMO. Whichever detects the most bugs at compile time is best. Bruce From owner-freebsd-standards@FreeBSD.ORG Wed Apr 16 10:27:27 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 A5F0037B401 for ; Wed, 16 Apr 2003 10:27:27 -0700 (PDT) Received: from falcon.midgard.homeip.net (h76n3fls20o913.telia.com [213.67.148.76]) by mx1.FreeBSD.org (Postfix) with SMTP id 69BC643FA3 for ; Wed, 16 Apr 2003 10:27:25 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: (qmail 13701 invoked by uid 1001); 16 Apr 2003 17:27:23 -0000 Date: Wed, 16 Apr 2003 19:27:23 +0200 From: Erik Trulsson To: Bruce Evans Message-ID: <20030416172723.GA13575@falcon.midgard.homeip.net> Mail-Followup-To: Bruce Evans , Jens Schweikhardt , freebsd-standards@freebsd.org, lamer@properfucked.net References: <200304161249.h3GCntqZ071047@freefall.freebsd.org> <20030416125715.GA12300@falcon.midgard.homeip.net> <20030417005708.D6167@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030417005708.D6167@gamplex.bde.org> User-Agent: Mutt/1.5.4i cc: lamer@properfucked.net cc: freebsd-standards@freebsd.org cc: Jens Schweikhardt Subject: Re: standards/50889: NULL defined as 0 instead of (void *)0 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, 16 Apr 2003 17:27:28 -0000 On Thu, Apr 17, 2003 at 01:00:40AM +1000, Bruce Evans wrote: > On Wed, 16 Apr 2003, Erik Trulsson wrote: > > > On Wed, Apr 16, 2003 at 05:49:55AM -0700, Jens Schweikhardt wrote: > > > I agree, though, that it may be desirable to > > > #define NULL ((void*)0) > > > > Unless you want to use the same definition for both C and C++. > > In C++ the only valid way of defining NULL is > > > > #define NULL 0 > > > > because in C++ there is no automatic conversion between "pointer to > > void" and other pointer types as there is in C. > > I agree. It may be, and is, also desireable to define NULL as 0. > A bit more desireable IMO. Whichever detects the most bugs at compile > time is best. Yes, but the problem here is that each of the two definitions detects some bugs but also hides some bugs. The bugs that are detected/hidden are of course different between the two definitions. Thus, there is not really any "best" definition and and which one detects most bugs depends on what kind of bugs a program has. Well written programs must be able to cope with either definition and since both variants have their advantages and disadvantages it really doesn't matter much which definition is used. They will both work about equally well. (Except that, as noted above, for C++ the only valid definition of NULL is as 0, so if one wants to share the include files between C and C++ (and one probably wants to do that) and don't want to mess around with #ifdefs to have different definitions for C and C++ (which seems a bit pointless to me) there is not much choice on what definition to use.) -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-standards@FreeBSD.ORG Wed Apr 16 16:20:12 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 D7B5637B401 for ; Wed, 16 Apr 2003 16:20:12 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8118343F75 for ; Wed, 16 Apr 2003 16:20:12 -0700 (PDT) (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 h3GNKBUp094408 for ; Wed, 16 Apr 2003 16:20:11 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h3GNKB0Z094407; Wed, 16 Apr 2003 16:20:11 -0700 (PDT) Date: Wed, 16 Apr 2003 16:20:11 -0700 (PDT) Message-Id: <200304162320.h3GNKB0Z094407@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Alexander Kabaev Subject: Re: standards/50523: Deprecate , add X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alexander Kabaev List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 23:20:13 -0000 The following reply was made to PR standards/50523; it has been noted by GNATS. From: Alexander Kabaev To: rodrigc@attbi.com Cc: freebsd-gnats-submit@FreeBSD.org, rodrigc@attbi.com, kan@FreeBSD.org Subject: Re: standards/50523: Deprecate , add Date: Wed, 16 Apr 2003 19:11:43 -0400 I already submitted a repo-copy request. I will handle the rest when files are ready. On Wed, 16 Apr 2003 10:07:45 -0400 (EDT) rodrigc@attbi.com wrote: > > Craig, > > > > the patch looks OK, but I think this should be handled through > > repo-copy so that the history on deprecated files will get lost. > > > > -- > > Alexander Kabaev > > Hi, > > I am not a committer, so do not know how to proceed from here. > Is there anyone who is interested in shepherding this patch in? > -- > Craig Rodrigues > rodrigc@attbi.com From owner-freebsd-standards@FreeBSD.ORG Sat Apr 19 14:58:34 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 9714337B401 for ; Sat, 19 Apr 2003 14:58:34 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F0AE43FDD for ; Sat, 19 Apr 2003 14:58:34 -0700 (PDT) (envelope-from leimy2k@mac.com) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h3JLwXjC014376 for ; Sat, 19 Apr 2003 14:58:33 -0700 (PDT) Received: from mac.com ([67.33.226.72]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id HDM2DL00.37T for ; Sat, 19 Apr 2003 14:58:33 -0700 Date: Sat, 19 Apr 2003 16:58:32 -0500 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: David Leimbach To: freebsd-standards@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <0FC33C7D-72B2-11D7-A08E-0003937E39E0@mac.com> X-Mailer: Apple Mail (2.552) Subject: Implementations of _r functions 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, 19 Apr 2003 21:58:34 -0000 They seem to be there now and on CURRENT some people are giving backtraces of the new functions being used! This is good but someone needs to update the C99 status page. I didn't do the getpwnam_r obviously so my name should come down from the chart. I have started looking into doing some extra regression testing of various pieces of FreeBSD. Libc is first on my list. I was also asked to try to implement some of the assembly stuff for libc for i386 platforms. I am looking into that as well. Dave From owner-freebsd-standards@FreeBSD.ORG Sat Apr 19 17:46:49 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 7E08437B401; Sat, 19 Apr 2003 17:46:49 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8D6443FBD; Sat, 19 Apr 2003 17:46:45 -0700 (PDT) (envelope-from freebsd@snark.ratmir.ru) Received: from snark.ratmir.ru (freebsd@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3K0kfC2052304; Sun, 20 Apr 2003 04:46:42 +0400 (MSD) (envelope-from freebsd@snark.ratmir.ru) Received: (from freebsd@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3K0kdjN052299; Sun, 20 Apr 2003 04:46:39 +0400 (MSD) Date: Sun, 20 Apr 2003 04:46:39 +0400 From: Alex Semenyaka To: freebsd-performance@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-standards@freebsd.org Message-ID: <20030420004639.GA52081@snark.ratmir.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.4i Subject: tjr@@freebsd.org, imp@freebsd.org, ru@freebsd.org 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, 20 Apr 2003 00:46:50 -0000 Hi, I've heard a lot of recommendation about where I shoud show my patch and the results of performance changes because of it. So I gathered all advices into To: and CC: fields. Sorry, if there are unnecessary addresses (which then?). Also as I was told the final patch I've send as the PR. Brief description what was done: I've chanched the arithmitics in the /bin/= sh =66rom 32 bits to 64 bits. There are some doubts that it conforms to the standards: it does, I have send a quotations to -standards, there were no objections. Couple of people advuces me to use intmax_t and %jd - I've rewr= itten the patch, now there is those species instead of long long and %qd. The last question was performance, I will show the results of measurements below. The patch can be found in the attach to this message or in the PR bin/51171. Also I've added the overflow control to the addition, substraction and multiplication. There is pretty small overhead (see data below) so I decided it harmless. First, here is the processor description in the box I've run the tests. CPU: Intel Pentium III (1002.28-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x68a Stepping =3D 10 Features=3D0x387f9ff real memory =3D 268435456 (262144K bytes) avail memory =3D 256475136 (250464K bytes) The tests was a set of 12 scripts with the following structure: for x in `jot 300000` do done and operations were "" (just no operation, empty loop), i=3D$(($i+1)), i=3D$(($i+$m)) (here is _two_ variables), i=3D$(($i*1)), i=3D$(($i*$m)), i= =3D$(($i/1)), i=3D$(($i/$m)), i=3D$(($i<<1)), i=3D$(($i<<$m)), i=3D$(($i||1)), i=3D$(($i|= |$m)), i=3D$((~$i)). In the tests with two variables second one ($m) was always eq= ual to 1. Starting value of $i was also 1.` I've run those twelve scripts first with the 64-bit shell without overflow control and compared with 32-bit shell: Test Time Difference Arith. No Old New Abs %% operation ----+----------------+-------------------------------- 0 1.35 1.36 0.04 0.99% no op 1 5.12 5.36 0.72 4.69% i=3D$(($i+1)) 2 5.17 5.43 0.78 5.03% i=3D$(($i+$a)) 3 4.39 4.57 0.55 4.18% i=3D$(($i*1)) 4 4.43 4.64 0.64 4.82% i=3D$(($i*$m)) 5 4.40 4.62 0.67 5.08% i=3D$(($i/1)) 6 4.45 4.68 0.68 5.09% i=3D$(($i/$m)) 7 5.20 6.37 3.51 22.50% i=3D$(($i<<1)) 8 5.25 6.42 3.51 22.27% i=3D$(($i<<$m)) 9 4.52 4.67 0.45 3.32% i=3D$(($i||1)) 10 4.58 4.73 0.44 3.20% i=3D$(($i||$m)) 11 4.30 4.38 0.25 1.94% i=3D$((~$i)) As you can see, even for arithmetic-only script the overhead is not too big except with one case: shift operation. I decided to investigate is it usual script operation. I've went through all scripts I could find in my FreeBSD box. I've searched them with "locate .sh | grep '\.sh$'". There were a lot of them: $ locate .sh | grep '\.sh$' | wc -l 1637 But there was no any script that uses the shift operation. Good, but not enough. I've take the script that uses arithmetics and do some other job, ttfadmin.sh from the Abiword package. I've run in 10000 times in the loop with both (64-bit and 32-bit) shells. As an argument it received empty directory so no work has been done, just run, check pars, found no files, exit. It takes 65.35 seconds in the first case and 65.30 second in the seco= nd one. So the the time that arithmetics takes during the real script execution is too small in comparison to total running time (obviously: arithmetics is in-core calculations while any script usually run some external programs etc, and at least I/O is involved). Then I've run tests with the addition and multiplication to compare 64-bit shells compiled without the overview control and with it. In the last case I've turned that control on by setting corresponding command line option (-O in my patch). Here are results: 1 5.24 5.26 0.08 0.51% 2 5.31 5.34 0.08 0.50% 3 4.53 4.57 0.14 1.03% 4 4.60 4.65 0.14 1.01% You can see, the difference is just negligible.=20 So I hope I've answered all questions were asked about that 64-bit modifica= tion. All apprehensions are, I hope, dismissed. Probably, after the last look of the responsible person it can be committed, am I right? Thanks! SY, Alex From owner-freebsd-standards@FreeBSD.ORG Sat Apr 19 18:10:50 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 9572837B401; Sat, 19 Apr 2003 18:10:50 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3AC643FE1; Sat, 19 Apr 2003 18:10:46 -0700 (PDT) (envelope-from freebsd@snark.ratmir.ru) Received: from snark.ratmir.ru (freebsd@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3K1AeC2052397; Sun, 20 Apr 2003 05:10:41 +0400 (MSD) (envelope-from freebsd@snark.ratmir.ru) Received: (from freebsd@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3K1Ad4h052396; Sun, 20 Apr 2003 05:10:39 +0400 (MSD) Date: Sun, 20 Apr 2003 05:10:39 +0400 From: Alex Semenyaka To: freebsd-performance@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-standards@freebsd.org Message-ID: <20030420011039.GC52081@snark.ratmir.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.4i cc: imp@freebsd.org cc: tjr@freebsd.org Subject: /bin/sh and 32-bit arithmetics [CORRECTED] 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, 20 Apr 2003 01:10:51 -0000 I'm EXTREMELY sorry about the previous wrong posting, just mixed the header fields. Sorry again! Here is the correct one. Especially sorry to those guys whose addresses get into the Subject line. J= ust a mistake, nothing personal :( ---------------------------------------------------------------------------= -- Hi, I've heard a lot of recommendation about where I shoud show my patch and the results of performance changes because of it. So I gathered all advices into To: and CC: fields. Sorry, if there are unnecessary addresses (which then?). Also as I was told the final patch I've send as the PR. Brief description what was done: I've chanched the arithmitics in the /bin/= sh =66rom 32 bits to 64 bits. There are some doubts that it conforms to the standards: it does, I have send a quotations to -standards, there were no objections. Couple of people advuces me to use intmax_t and %jd - I've rewr= itten the patch, now there is those species instead of long long and %qd. The last question was performance, I will show the results of measurements below. The patch can be found in the attach to this message or in the PR bin/51171. Also I've added the overflow control to the addition, substraction and multiplication. There is pretty small overhead (see data below) so I decided it harmless. First, here is the processor description in the box I've run the tests. CPU: Intel Pentium III (1002.28-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x68a Stepping =3D 10 Features=3D0x387f9ff real memory =3D 268435456 (262144K bytes) avail memory =3D 256475136 (250464K bytes) The tests was a set of 12 scripts with the following structure: for x in `jot 300000` do done and operations were "" (just no operation, empty loop), i=3D$(($i+1)), i=3D$(($i+$m)) (here is _two_ variables), i=3D$(($i*1)), i=3D$(($i*$m)), i= =3D$(($i/1)), i=3D$(($i/$m)), i=3D$(($i<<1)), i=3D$(($i<<$m)), i=3D$(($i||1)), i=3D$(($i|= |$m)), i=3D$((~$i)). In the tests with two variables second one ($m) was always eq= ual to 1. Starting value of $i was also 1.` I've run those twelve scripts first with the 64-bit shell without overflow control and compared with 32-bit shell: Test Time Difference Arith. No Old New Abs %% operation ----+----------------+-------------------------------- 0 1.35 1.36 0.04 0.99% no op 1 5.12 5.36 0.72 4.69% i=3D$(($i+1)) 2 5.17 5.43 0.78 5.03% i=3D$(($i+$a)) 3 4.39 4.57 0.55 4.18% i=3D$(($i*1)) 4 4.43 4.64 0.64 4.82% i=3D$(($i*$m)) 5 4.40 4.62 0.67 5.08% i=3D$(($i/1)) 6 4.45 4.68 0.68 5.09% i=3D$(($i/$m)) 7 5.20 6.37 3.51 22.50% i=3D$(($i<<1)) 8 5.25 6.42 3.51 22.27% i=3D$(($i<<$m)) 9 4.52 4.67 0.45 3.32% i=3D$(($i||1)) 10 4.58 4.73 0.44 3.20% i=3D$(($i||$m)) 11 4.30 4.38 0.25 1.94% i=3D$((~$i)) As you can see, even for arithmetic-only script the overhead is not too big except with one case: shift operation. I decided to investigate is it usual script operation. I've went through all scripts I could find in my FreeBSD box. I've searched them with "locate .sh | grep '\.sh$'". There were a lot of them: $ locate .sh | grep '\.sh$' | wc -l 1637 But there was no any script that uses the shift operation. Good, but not enough. I've take the script that uses arithmetics and do some other job, ttfadmin.sh from the Abiword package. I've run in 10000 times in the loop with both (64-bit and 32-bit) shells. As an argument it received empty directory so no work has been done, just run, check pars, found no files, exit. It takes 65.35 seconds in the first case and 65.30 second in the seco= nd one. So the the time that arithmetics takes during the real script execution is too small in comparison to total running time (obviously: arithmetics is in-core calculations while any script usually run some external programs etc, and at least I/O is involved). Then I've run tests with the addition and multiplication to compare 64-bit shells compiled without the overview control and with it. In the last case I've turned that control on by setting corresponding command line option (-O in my patch). Here are results: 1 5.24 5.26 0.08 0.51% 2 5.31 5.34 0.08 0.50% 3 4.53 4.57 0.14 1.03% 4 4.60 4.65 0.14 1.01% You can see, the difference is just negligible.=20 So I hope I've answered all questions were asked about that 64-bit modifica= tion. All apprehensions are, I hope, dismissed. Probably, after the last look of the responsible person it can be committed, am I right? Thanks! SY, Alex From owner-freebsd-standards@FreeBSD.ORG Sat Apr 19 18:34: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 DCE4537B401; Sat, 19 Apr 2003 18:34:05 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id B53A043F3F; Sat, 19 Apr 2003 18:34:03 -0700 (PDT) (envelope-from freebsd@snark.ratmir.ru) Received: from snark.ratmir.ru (freebsd@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3K1Y0C2073365; Sun, 20 Apr 2003 05:34:00 +0400 (MSD) (envelope-from freebsd@snark.ratmir.ru) Received: (from freebsd@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3K1Y0gn073364; Sun, 20 Apr 2003 05:34:00 +0400 (MSD) Date: Sun, 20 Apr 2003 05:34:00 +0400 From: Alex Semenyaka To: Alex Semenyaka Message-ID: <20030420013400.GB52428@snark.ratmir.ru> References: <20030420011039.GC52081@snark.ratmir.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030420011039.GC52081@snark.ratmir.ru> User-Agent: Mutt/1.5.4i cc: freebsd-current@freebsd.org cc: tjr@freebsd.org cc: imp@freebsd.org cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: freebsd-standards@freebsd.org Subject: Re: /bin/sh and 32-bit arithmetics [CORRECTED] 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, 20 Apr 2003 01:34:06 -0000 ...ghmmm... sorry and sorry... and here the patch, it is pretty small: diff -u -r -U 2 -b ../sh.old/Makefile ./Makefile --- ../sh.old/Makefile Sat Apr 19 23:22:31 2003 +++ ./Makefile Sun Apr 20 02:47:41 2003 @@ -19,5 +19,5 @@ LFLAGS= -8 # 8-bit lex scanner for arithmetic -CFLAGS+=-DSHELL -I. -I${.CURDIR} +CFLAGS+=-DSHELL -I. -I${.CURDIR} -DOVERFLOW # for debug: #CFLAGS+= -g -DDEBUG=2 -pg diff -u -r -U 2 -b ../sh.old/arith.h ./arith.h --- ../sh.old/arith.h Fri Jul 19 08:38:51 2002 +++ ./arith.h Sun Apr 20 02:37:37 2003 @@ -35,4 +35,7 @@ */ -int arith(char *); +/* XXX some day probably should go to /usr/include/machine/_inttypes.h */ +#define MAXINT_LEN 20 + +intmax_t arith(char *); int expcmd(int , char **); diff -u -r -U 2 -b ../sh.old/arith.y ./arith.y --- ../sh.old/arith.y Fri Jul 19 08:38:51 2002 +++ ./arith.y Sun Apr 20 03:52:31 2003 @@ -1,2 +1,13 @@ +%{ +#include +#ifdef OVERFLOW +#include "options.h" +#endif + +#define YYSTYPE intmax_t + +static intmax_t arith_res; +%} + %token ARITH_NUM ARITH_LPAREN ARITH_RPAREN @@ -15,5 +26,6 @@ exp: expr = { - return ($1); + arith_res = $1; + return (0); } ; @@ -34,7 +46,25 @@ | expr ARITH_LSHIFT expr = { $$ = $1 << $3; } | expr ARITH_RSHIFT expr = { $$ = $1 >> $3; } - | expr ARITH_ADD expr = { $$ = $1 + $3; } - | expr ARITH_SUB expr = { $$ = $1 - $3; } - | expr ARITH_MUL expr = { $$ = $1 * $3; } + | expr ARITH_ADD expr = { + $$ = $1 + $3; +#ifdef OVERFLOW + if (Oflag && is_add_overflow($1, $3, $$)) + yyerror("overflow in"); +#endif + } + | expr ARITH_SUB expr = { + $$ = $1 - $3; +#ifdef OVERFLOW + if (Oflag && is_add_overflow($1, -$3, $$)) + yyerror("overflow in"); +#endif + } + | expr ARITH_MUL expr = { + $$ = $1 * $3; +#ifdef OVERFLOW + if (Oflag && $$/$1 != $3 ) + yyerror("overflow in"); +#endif + } | expr ARITH_DIV expr = { if ($3 == 0) @@ -110,16 +140,24 @@ int -arith(char *s) +is_add_overflow(intmax_t a, intmax_t b, intmax_t s) { - long result; + if (a > 0 && b > 0 && s <= 0) + return 1; + if (a < 0 && b < 0 && s >= 0) + return 1; + return 0; +} +intmax_t +arith(char *s) +{ arith_buf = arith_startbuf = s; INTOFF; - result = yyparse(); + yyparse(); arith_lex_reset(); /* reprime lex */ INTON; - return (result); + return (arith_res); } @@ -143,5 +181,5 @@ char *concat; char **ap; - long i; + intmax_t i; if (argc > 1) { @@ -168,5 +206,5 @@ i = arith(p); - out1fmt("%ld\n", i); + out1fmt("%jd\n", i); return (! i); } diff -u -r -U 2 -b ../sh.old/arith_lex.l ./arith_lex.l --- ../sh.old/arith_lex.l Fri Jul 19 08:38:51 2002 +++ ./arith_lex.l Sun Apr 20 02:37:37 2003 @@ -44,8 +44,9 @@ #endif /* not lint */ +#include #include "y.tab.h" #include "error.h" -extern int yylval; +extern intmax_t yylval; extern char *arith_buf, *arith_startbuf; #undef YY_INPUT @@ -57,5 +58,5 @@ %% [ \t\n] { ; } -[0-9]+ { yylval = atol(yytext); return(ARITH_NUM); } +[0-9]+ { yylval = strtoll(yytext, NULL, 10); return(ARITH_NUM); } "(" { return(ARITH_LPAREN); } ")" { return(ARITH_RPAREN); } diff -u -r -U 2 -b ../sh.old/expand.c ./expand.c --- ../sh.old/expand.c Fri Jan 17 14:37:03 2003 +++ ./expand.c Sun Apr 20 02:37:37 2003 @@ -46,4 +46,5 @@ #include #include +#include #include #include @@ -367,5 +368,5 @@ { char *p, *start; - int result; + intmax_t result; int begoff; int quotes = flag & (EXP_FULL | EXP_CASE | EXP_REDIR); @@ -383,8 +384,8 @@ * characters have to be processed left to right. */ -#if INT_MAX / 1000000000 >= 10 || INT_MIN / 1000000000 <= -10 -#error "integers with more than 10 digits are not supported" -#endif - CHECKSTRSPACE(12 - 2, expdest); +//#if INT_MAX / 1000000000 >= 10 || INT_MIN / 1000000000 <= -10 +//#error "integers with more than 10 digits are not supported" +//#endif + CHECKSTRSPACE(MAXINT_LEN, expdest); USTPUTC('\0', expdest); start = stackblock(); @@ -408,5 +409,5 @@ rmescapes(p+2); result = arith(p+2); - fmtstr(p, 12, "%d", result); + fmtstr(p, MAXINT_LEN + 2, "%qd", result); while (*p++) ; diff -u -r -U 2 -b ../sh.old/options.h ./options.h --- ../sh.old/options.h Tue Aug 27 05:36:28 2002 +++ ./options.h Sun Apr 20 02:24:46 2003 @@ -67,6 +67,13 @@ #define Tflag optlist[16].val #define Pflag optlist[17].val +#ifdef OVERFLOW +#define Oflag optlist[18].val +#endif +#ifdef OVERFLOW +#define NOPTS 19 +#else #define NOPTS 18 +#endif struct optent { @@ -96,4 +103,7 @@ { "trapsasync", 'T', 0 }, { "physical", 'P', 0 }, +#ifdef OVERFLOW + { "overflow", 'O', 0 }, +#endif }; #else diff -u -r -U 2 -b ../sh.old/sh.1 ./sh.1 --- ../sh.old/sh.1 Tue Feb 25 13:27:12 2003 +++ ./sh.1 Sun Apr 20 02:52:02 2003 @@ -44,5 +44,5 @@ .Sh SYNOPSIS .Nm -.Op Fl /+abCEefIimnPpsTuVvx +.Op Fl /+abCEefIimnOPpsTuVvx .Op Fl /+o Ar longname .Op Fl c Ar string @@ -226,4 +226,6 @@ execute them. This is useful for checking the syntax of shell scripts. +.It Fl O Li interactive +If compiled with the overflow checks, turn them during arithmetic operations on. .It Fl P Li physical Change the default for the From owner-freebsd-standards@FreeBSD.ORG Sat Apr 19 18:50:29 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 19B6437B401; Sat, 19 Apr 2003 18:50:29 -0700 (PDT) Date: Sat, 19 Apr 2003 20:50:29 -0500 From: Juli Mallett To: Alex Semenyaka Message-ID: <20030419205028.A78458@FreeBSD.org> References: <20030420011039.GC52081@snark.ratmir.ru> <20030420013400.GB52428@snark.ratmir.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030420013400.GB52428@snark.ratmir.ru>; from alexs@ratmir.ru on Sun, Apr 20, 2003 at 05:34:00AM +0400 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-Negacore: Yes X-Title: Code Maven X-Authentication-Warning: localhost: juli pwned teh intarweb cc: freebsd-standards@freebsd.org cc: Alex Semenyaka Subject: Re: /bin/sh and 32-bit arithmetics [CORRECTED] 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, 20 Apr 2003 01:50:29 -0000 * De: Alex Semenyaka [ Data: 2003-04-19 ] [ Subjecte: Re: /bin/sh and 32-bit arithmetics [CORRECTED] ] > ...ghmmm... sorry and sorry... and here the patch, it is pretty small: At a cursory glance: You are using quad_t (barf) formats for what is intmax_t, you really want to use %j not %q, and you may be doing more work than is necessary. Simply switching to "long" in place of "int" for everything (and LONG_ vs INT_) may be a better start than using intmax_t? intmax_t may be very slow, for some operations, and you may still have 128-bit intmax_t on a system with 64-bit long and 32-bit int, and 64-bit intmax_t on a system with 32-bit long and int, and 64-bit long long, thus an argument along the lines of "long makes the integer size gain a non-normalised thing" would be bogus, I think. A better argument might be for building i386 with 64-bit long (ha ha ha), and that seems what you want- a wider type on a sucky architecture ;) As for the INTMAX_LEN or whatnot, that's bogusish. There are ways of (at run time) deducing the maximum size of a buffer for a , probably you can shove them into some init routine that sh surely has. Also, I don't know how we feel about C++/C99 style comments in the base system. Thanx, juli (who imagines bde would have better advice.) -- juli mallett. email: jmallett@freebsd.org; aim: bsdflata; efnet: juli; From owner-freebsd-standards@FreeBSD.ORG Sat Apr 19 18:54:26 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 EE6DF37B401; Sat, 19 Apr 2003 18:54:26 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EF4043FAF; Sat, 19 Apr 2003 18:54:26 -0700 (PDT) (envelope-from jdp@FreeBSD.org) Received: from freefall.freebsd.org (jdp@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h3K1sQUp076266; Sat, 19 Apr 2003 18:54:26 -0700 (PDT) (envelope-from jdp@freefall.freebsd.org) Received: (from jdp@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h3K1sPgR076262; Sat, 19 Apr 2003 18:54:25 -0700 (PDT) Date: Sat, 19 Apr 2003 18:54:25 -0700 (PDT) From: John Polstra Message-Id: <200304200154.h3K1sPgR076262@freefall.freebsd.org> To: osa@FreeBSD.org.ru, jdp@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: standards/50848: [PATCH] Implementation of pthread_[get|set]concurrency 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, 20 Apr 2003 01:54:27 -0000 Synopsis: [PATCH] Implementation of pthread_[get|set]concurrency State-Changed-From-To: open->closed State-Changed-By: jdp State-Changed-When: Sat Apr 19 18:53:31 PDT 2003 State-Changed-Why: Committed to -current, except for the portions which affect libpthread. I'll merge it to -stable in about a week. http://www.freebsd.org/cgi/query-pr.cgi?pr=50848 From owner-freebsd-standards@FreeBSD.ORG Sat Apr 19 19:16: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 41C7537B401; Sat, 19 Apr 2003 19:16:30 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 792D943FB1; Sat, 19 Apr 2003 19:16:27 -0700 (PDT) (envelope-from alexs@snark.ratmir.ru) Received: from snark.ratmir.ru (alexs@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3K2GOC2073586; Sun, 20 Apr 2003 06:16:25 +0400 (MSD) (envelope-from alexs@snark.ratmir.ru) Received: (from alexs@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3K2GNcJ073585; Sun, 20 Apr 2003 06:16:23 +0400 (MSD) Date: Sun, 20 Apr 2003 06:16:23 +0400 From: Alex Semenyaka To: Juli Mallett Message-ID: <20030420021623.GA73500@snark.ratmir.ru> References: <20030420011039.GC52081@snark.ratmir.ru> <20030420013400.GB52428@snark.ratmir.ru> <20030419205028.A78458@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030419205028.A78458@FreeBSD.org> User-Agent: Mutt/1.5.4i cc: freebsd-standards@FreeBSD.ORG cc: Alex Semenyaka cc: Alex Semenyaka Subject: Re: /bin/sh and 32-bit arithmetics [CORRECTED] 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, 20 Apr 2003 02:16:30 -0000 On Sat, Apr 19, 2003 at 08:50:29PM -0500, Juli Mallett wrote: > may be doing more work than is necessary. Simply switching to > "long" in place of "int" for everything (and LONG_ vs INT_) may be > a better start than using intmax_t? intmax_t may be very slow, That %qd is just a misktake, sorry. Should be %jd. Wrong merge. Then, I used jost 'long long' but people from -hackers told me that the right way is intmax_t. Well, if it conforms to the current style I can switch it back. Or, use some kind of explicit type. Just long instead of int is not enough for i386 since it is 32-bit type. > might be for building i386 with 64-bit long (ha ha ha), and that > seems what you want- a wider type on a sucky architecture ;) Well it is a bit sucky but not too much _here_ actually. There is nothing special with 64-bit arithmetics. > As for the INTMAX_LEN or whatnot, that's bogusish. There are ways > of (at run time) deducing the maximum size of a buffer for a I asked people about the _typical_ solution. Nobody answered, unfortunatelly. > , probably you can shove them into some init routine that > sh surely has. > > Also, I don't know how we feel about C++/C99 style comments in > the base system. Oh, I see. I'll change it, it is the easiest thing here > Thanx, > juli (who imagines bde would have better advice.) Really would like to read any opinion from the experienced people. SY, Alex From owner-freebsd-standards@FreeBSD.ORG Sat Apr 19 19:44: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 6510637B401; Sat, 19 Apr 2003 19:44:42 -0700 (PDT) Received: from snark.ratmir.ru (snark.ratmir.ru [213.24.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8532343FA3; Sat, 19 Apr 2003 19:44:36 -0700 (PDT) (envelope-from alexs@snark.ratmir.ru) Received: from snark.ratmir.ru (alexs@localhost [127.0.0.1]) by snark.ratmir.ru (8.12.9/8.12.9) with ESMTP id h3K2iWC2073730; Sun, 20 Apr 2003 06:44:33 +0400 (MSD) (envelope-from alexs@snark.ratmir.ru) Received: (from alexs@localhost) by snark.ratmir.ru (8.12.9/8.12.9/Submit) id h3K2iUdZ073725; Sun, 20 Apr 2003 06:44:30 +0400 (MSD) Date: Sun, 20 Apr 2003 06:44:30 +0400 From: Alex Semenyaka To: Juli Mallett Message-ID: <20030420024430.GA73433@snark.ratmir.ru> References: <20030420011039.GC52081@snark.ratmir.ru> <20030420013400.GB52428@snark.ratmir.ru> <20030419205028.A78458@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030419205028.A78458@FreeBSD.org> User-Agent: Mutt/1.5.4i cc: freebsd-standards@FreeBSD.ORG cc: Alex Semenyaka Subject: Re: /bin/sh and 32-bit arithmetics [CORRECTED] 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, 20 Apr 2003 02:44:42 -0000 On Sat, Apr 19, 2003 at 08:50:29PM -0500, Juli Mallett wrote: > might be for building i386 with 64-bit long (ha ha ha), and that By the way, it is not the option. First, as you can see, bacause of fixed size buffer. Second, there is a special hack (which I do not like and thus I've fixed it) in the original code when the value of the expression is passed as a returning value of yyparse(), which is int. Thus this hack 1) limits us to the type 'int' and 2) breaks the yyparse() semantics (yyparse should return YYACCEPT or YYABORT). Therefore it is not enough just to trbuild /bin/sh with different compilations options, some changes still should be done. Did I get it right that it is necessary to 1) fix '%qd' 2) fix C++-style comments 3) (possible) use explicit 64-bit type? SY, Alex