From owner-freebsd-arch@FreeBSD.ORG Wed Mar 11 18:44:08 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69D49C51 for ; Wed, 11 Mar 2015 18:44:08 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bbn0102.outbound.protection.outlook.com [157.56.111.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F13C3A82 for ; Wed, 11 Mar 2015 18:44:07 +0000 (UTC) Received: from BLUPR0501MB1060.namprd05.prod.outlook.com (25.160.36.150) by BY1PR0501MB1542.namprd05.prod.outlook.com (25.160.203.140) with Microsoft SMTP Server (TLS) id 15.1.106.15; Wed, 11 Mar 2015 18:29:41 +0000 Received: from BLUPR0501MB1060.namprd05.prod.outlook.com ([25.160.36.150]) by BLUPR0501MB1060.namprd05.prod.outlook.com ([25.160.36.150]) with mapi id 15.01.0099.004; Wed, 11 Mar 2015 18:29:40 +0000 From: Anuranjan Shukla To: hiren panchasara , Simon Gerraty Subject: Re: Buggy sbspace() on 64bit builds? Thread-Topic: Buggy sbspace() on 64bit builds? Thread-Index: AQHQQa9oYD6vE33IJEufQkyrNnicWZzjUieAgABadwCAALPZAIAzbd4A//+LoIA= Date: Wed, 11 Mar 2015 18:29:39 +0000 Message-ID: References: <20150206183036.S1246@besplex.bde.org> <5977.1423271024@chaos> <20150311182612.GL88380@strugglingcoder.info> In-Reply-To: <20150311182612.GL88380@strugglingcoder.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [66.129.241.12] authentication-results: strugglingcoder.info; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1542; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(479174004)(51704005)(77156002)(122556002)(62966003)(2950100001)(92566002)(83506001)(87936001)(19580405001)(19580395003)(102836002)(46102003)(76176999)(2900100001)(54356999)(40100003)(50986999)(86362001)(106116001)(99286002)(93886004)(2656002)(36756003)(66066001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1542; H:BLUPR0501MB1060.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BY1PR0501MB1542; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1542; x-forefront-prvs: 0512CC5201 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 18:29:39.9615 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1542 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:44:08 -0000 Hi Hiren, It's been committed to HEAD, r278729. Thanks. On 3/11/15, 11:26 AM, "hiren panchasara" wrote: >On 02/06/15 at 05:03P, Simon J. Gerraty wrote: >> Anuranjan Shukla wrote: >> > this, along with return value being 'int' acceptable as a final >> > determination? >>=20 >> It is ok for the function to return long, >> so long as an int is used internally. >> Casting the int to long - implicit on return does no harm. >>=20 >> #include >> #include >> #include >>=20 >> int >> main(int argc, char *argv[]) >> { >> uint a, b; >> long r1; >> int r2; >>=20 >> a =3D 1; >> b =3D 2; >>=20 >> r1 =3D a - b; >> r2 =3D a - b; >>=20 >> printf("r1=3D%ld\nr2=3D%d\nr3=3D%ld\n", r1, r2, (long)r2); >> exit(0); >> } >>=20 >> r1=3D4294967295 >> r2=3D-1 >> r3=3D-1 >>=20 >> so I think just using 'int' internally should work for now, >> perhaps with a comment saying the object size should match >> those being subtracted etc. > >Hi Simon/Anu, > >Has this been committed yet? I believe I am running into something >similar in our stable10 build. I am not certain though. In any case, >this should be committed/mfc'd. > >Cheers, >Hiren