From owner-freebsd-arch@FreeBSD.ORG Thu Aug 12 19:20:58 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2C081065679 for ; Thu, 12 Aug 2010 19:20:58 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 471D18FC0A for ; Thu, 12 Aug 2010 19:20:57 +0000 (UTC) Received: by ewy26 with SMTP id 26so1074876ewy.13 for ; Thu, 12 Aug 2010 12:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=vEB23y5D0F4MN72nO+otGINAmQgtMHZSwd3kIcl1Kuc=; b=sTJ6Q2MXl9q065PKJrd2Q88PUmvL0mrmP29SVlfot1hibsr5o+leIfXlfUssCNGV/6 W9kHbta3ZX45xqAZnTSO6jKbAj3naPXrWVyeoPxZdCGg+fUKrarf6jiOUCLlDvprTyjh NqdFX/j+LM2DmL8QD0kDKneBQuARqhmba4LR0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=elEHBrSBXsF2kFa0c2FXAaXkzeJ8bI2UjRQlNyfSVsMe9qC5J1HxFdUnbQF4Vm3X+v zOEt2ghtzpECf8O7yefvy0U6zyXrOHwluAE+jK0ue0h8VPqCy5HFH2tBlbfUaJEBOHJw 5ojMqTPa/Giv0y9YGAiiX7gyc/COZB8nNtkjM= MIME-Version: 1.0 Received: by 10.213.22.9 with SMTP id l9mr588251ebb.78.1281640857146; Thu, 12 Aug 2010 12:20:57 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.213.10.196 with HTTP; Thu, 12 Aug 2010 12:20:57 -0700 (PDT) Date: Thu, 12 Aug 2010 12:20:57 -0700 X-Google-Sender-Auth: tKbFa55vfjHRPTFhrgui4sC8zcY Message-ID: From: mdf@FreeBSD.org To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 19:20:58 -0000 Looking over the arch-specific definitions, using uintptr_t and size_t would not affect the actual width of these sizes. However, it would simplify e.g. conformant printf(9) statements, since there is an approved specifier for size_t and, while there isn't one for uintptr_t, ptrdiff_t is pretty close (Bruce, is there a better specifier)? Admittedly, this isn't the simplest of undertakings, as there are 590 instances of vm_size_t in the FreeBSD source code and 3887 of vm_offset_t. Has this proposal made the rounds before and been shot down for some reason? Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Thu Aug 12 19:56:55 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 941071065693; Thu, 12 Aug 2010 19:56:55 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 312EA8FC0A; Thu, 12 Aug 2010 19:56:55 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 3AAB82A28CE3; Thu, 12 Aug 2010 21:56:54 +0200 (CEST) Date: Thu, 12 Aug 2010 21:56:54 +0200 From: Ed Schouten To: mdf@FreeBSD.org Message-ID: <20100812195654.GB2978@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arch@freebsd.org Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 19:56:55 -0000 --7iMSBzlTiPOCCT2k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Matthew, * mdf@FreeBSD.org wrote: > Looking over the arch-specific definitions, using uintptr_t and size_t > would not affect the actual width of these sizes. However, it would > simplify e.g. conformant printf(9) statements, since there is an > approved specifier for size_t and, while there isn't one for > uintptr_t, ptrdiff_t is pretty close (Bruce, is there a better > specifier)? Not that I know any architecture we support which does this, but what happens if userspace has a larger address space than kernelspace? Say, we ever have some kind of architecture with a 32-bit kernel running 64-bit userspace applications. --=20 Ed Schouten WWW: http://80386.nl/ --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxkUgYACgkQ52SDGA2eCwV55ACeNavLAwupiKUZa/1IUxlmUZq+ YBIAnjLcRCsPKYC33kUVcAhl5wqy51KR =sEuH -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k-- From owner-freebsd-arch@FreeBSD.ORG Thu Aug 12 20:01:33 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6F5F106566C for ; Thu, 12 Aug 2010 20:01:33 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 33C318FC19 for ; Thu, 12 Aug 2010 20:01:32 +0000 (UTC) Received: by eyh6 with SMTP id 6so1100132eyh.13 for ; Thu, 12 Aug 2010 13:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=zFuvjoa05Lcq6HTMsoEBMqPXxZSoAxhb7yZ5vSGE9L8=; b=HbMBxIRBzUcWkH3XegbBQ8jJkW+K/RSvKdoyWAODABC3yDA7un66+PoiR1bwqsaV0i yI63Iic2OoRpQCUqW4WlrAdeUwdNId82abMKw9bb4KTGrujx23ExlwjyGhbJcrFeAn9y dZOF3vtyeoZFrVufNjGOzMf7+WE4HBTK5E3gg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=FAgO0wHmFZ63vrLvdNA6/oVglm9pGIrIXH9cu6DaxEXNDj2ltJDhQPf1meJfpURjWi GwJpULIXvqDUcB//nMtdqucz8FmQ0CdSQkFygxUNvAebXM7KBFCKjAgFWtClYijvRmNb bdWjuPXXR+yO4a1l2tKwpVj8PROFKKPzxPeGs= MIME-Version: 1.0 Received: by 10.213.62.206 with SMTP id y14mr7812539ebh.34.1281643291996; Thu, 12 Aug 2010 13:01:31 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.213.10.196 with HTTP; Thu, 12 Aug 2010 13:01:31 -0700 (PDT) In-Reply-To: <20100812195654.GB2978@hoeg.nl> References: <20100812195654.GB2978@hoeg.nl> Date: Thu, 12 Aug 2010 13:01:31 -0700 X-Google-Sender-Auth: jVu9EdlK9dudTtfTsN3NsMkTMzU Message-ID: From: mdf@FreeBSD.org To: Ed Schouten , freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 20:01:33 -0000 On Thu, Aug 12, 2010 at 12:56 PM, Ed Schouten wrote: > Hi Matthew, > > * mdf@FreeBSD.org wrote: >> Looking over the arch-specific definitions, using uintptr_t and size_t >> would not affect the actual width of these sizes. =A0However, it would >> simplify e.g. conformant printf(9) statements, since there is an >> approved specifier for size_t and, while there isn't one for >> uintptr_t, ptrdiff_t is pretty close (Bruce, is there a better >> specifier)? > > Not that I know any architecture we support which does this, but what > happens if userspace has a larger address space than kernelspace? Say, > we ever have some kind of architecture with a 32-bit kernel running > 64-bit userspace applications. True, in that instance 32-bit types wouldn't work. However, there is a *lot* of vm work needed to support 64 bit apps on a 32-bit kernel, and I really doubt there will be any investment in this for any of the 32-bit architectures. We had such a setup on AIX until the 32-bit kernel was killed, to support applications that needed more than 4GB before IBM was ready to do the 64-bit kernel project. Such a setup requires running on 64-bit hardware, and for whatever reason choosing to use the 32-bit kernel. I also can't think of any compelling reason to use a 32-bit kernel when a 64-bit one is available. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Fri Aug 13 09:46:45 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D58E51065679 for ; Fri, 13 Aug 2010 09:46:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id 6C48A8FC0C for ; Fri, 13 Aug 2010 09:46:44 +0000 (UTC) Received: from c122-106-147-41.carlnfd1.nsw.optusnet.com.au (c122-106-147-41.carlnfd1.nsw.optusnet.com.au [122.106.147.41]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7D9kgQt029308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 19:46:43 +1000 Date: Fri, 13 Aug 2010 19:46:42 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: mdf@FreeBSD.org In-Reply-To: Message-ID: <20100813191149.V12776@delplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 09:46:46 -0000 On Thu, 12 Aug 2010 mdf@FreeBSD.org wrote: > Looking over the arch-specific definitions, using uintptr_t and size_t > would not affect the actual width of these sizes. However, it would > simplify e.g. conformant printf(9) statements, since there is an > approved specifier for size_t and, while there isn't one for > uintptr_t, ptrdiff_t is pretty close (Bruce, is there a better > specifier)? > > Admittedly, this isn't the simplest of undertakings, as there are 590 > instances of vm_size_t in the FreeBSD source code and 3887 of > vm_offset_t. > > Has this proposal made the rounds before and been shot down for some reason? Ugh, typedefs exist to avoid hard-coding assumptions like this. Conformant printfs can't print any typedefed type except for ones with their own format letter (like size_t) without upcasting to a standard type. This is painful, but that is how typedefs work and printf doesn't work. Simplifying printing of things shouldn't be allowed to mess up the choice of types, especially in the kernel. When I looked at this for vm_offset_t, it didn't seem to cause many problems because most vm_offset_t's were printed using %x, and MD code can reasonably assume that vm_offset_t is u_int. Except it is u_long on 64-bit arches... I prefer to fix printf. There should be a %I format something like in sfio. Unfortunately C99 only standardized the PRI* mistake. I never learned exactly what %I does, but think it should have 2 variations, something like a plain %I causing the compiler to rewrite the literal format string, replacing %I with the appropriate Standard format, and %I for interpretation by the library. -Wformat has done all the work needed to determine the correct replacement for 10-20 years. So vm_offset's and size_t's would normally be printed using "%I[xu]" (no need for %z), but in message catalogues they would be printed using ("...%I*[xu] %I*[xu]...", ... sizeof(vm_offset_t) * CHAR_BIT, var_of_type_vm_offset_t, sizeof(size_t) * CHAR_BIT, var_of_type_vm_offset_t, ...) Except that came out too painful (almost as bad as using PRI*). I think I would usually avoid using %I if it were as messy as this, and use %j and require all integer args to be of type [u]intmax_t. %I could also be a more global directive (either at the front of every literal format string that wants rewriting for all args, or in CFLAGS for all strings in a file). Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Aug 13 10:43:49 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4DC31065698; Fri, 13 Aug 2010 10:43:49 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 868B18FC15; Fri, 13 Aug 2010 10:43:49 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4247C3F5B6; Fri, 13 Aug 2010 10:27:58 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o7DARvPl024589; Fri, 13 Aug 2010 10:27:58 GMT (envelope-from phk@critter.freebsd.dk) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 13 Aug 2010 19:46:42 +1000." <20100813191149.V12776@delplex.bde.org> Date: Fri, 13 Aug 2010 10:27:57 +0000 Message-ID: <24588.1281695277@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: mdf@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 10:43:49 -0000 In message <20100813191149.V12776@delplex.bde.org>, Bruce Evans writes: >On Thu, 12 Aug 2010 mdf@FreeBSD.org wrote: >I prefer to fix printf. [...] I never >learned exactly what %I does, but think it should have 2 variations, >something like a plain %I causing the compiler to rewrite the literal >format string, replacing %I with the appropriate Standard format, and >%I for interpretation by the library. I think printf is fundamentally broken, and "fixing" it by compiler magic would just galvanize the brokenness for all time. If you position is that C as a quality language is not salvageable, then I guess that makes sense, if you still have hopes for ISO-C coming to their senses, it does not. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 13 15:19:19 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9E2A1065673; Fri, 13 Aug 2010 15:19:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B9FA78FC12; Fri, 13 Aug 2010 15:19:19 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 63DA346B0D; Fri, 13 Aug 2010 11:19:19 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (75-48-78-116.lightspeed.cncrca.sbcglobal.net [75.48.78.116]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 51FB68A03C; Fri, 13 Aug 2010 11:19:17 -0400 (EDT) Message-ID: <4C656275.30201@FreeBSD.org> Date: Fri, 13 Aug 2010 11:19:17 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: mdf@FreeBSD.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 13 Aug 2010 11:19:17 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 15:19:20 -0000 mdf@FreeBSD.org wrote: > Looking over the arch-specific definitions, using uintptr_t and size_t > would not affect the actual width of these sizes. However, it would > simplify e.g. conformant printf(9) statements, since there is an > approved specifier for size_t and, while there isn't one for > uintptr_t, ptrdiff_t is pretty close (Bruce, is there a better > specifier)? > > Admittedly, this isn't the simplest of undertakings, as there are 590 > instances of vm_size_t in the FreeBSD source code and 3887 of > vm_offset_t. > > Has this proposal made the rounds before and been shot down for some reason? Hmm, I suspect vm_offset_t predates uintptr_t. I'm not sure the churn is really worth the effort involved especially as regards conflicts in future MFC's, etc. You also forgot vm_ooffset_t -> off_t. However, how often are vm_*_t values printed outside of temporary debug statements? They shouldn't be used in userland, so I'm not sure if there are enough printf() invocations to really justify the churn. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Aug 13 16:34:25 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3BB91065708; Fri, 13 Aug 2010 16:34:25 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 17D5C8FC0A; Fri, 13 Aug 2010 16:34:24 +0000 (UTC) Received: by ewy26 with SMTP id 26so1669012ewy.13 for ; Fri, 13 Aug 2010 09:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=qVy2pSjrVEpFpbs5ZKBTL0EzvwbfFxgnrk8T6RaSdSU=; b=mmy6Ogs7j1L1EpceWpnUTVk/BeNrYrpUeKg7/j5UxhB/SfuTbovnli6s4CcDdu4o9o jYl85eYMikSlH5yKAgmBIiP5MIQzfyuRgOv0nN3Gt8AKZHW1WuAhZi3ppaxcLhevO/w1 Q2U1TBVwLhzT6tGdXJdjzuBKs+7TnYwuOOnHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=PqUoyRDXSrUg+6cD/45kae97eCwDkMyiCSDygpKqMbkRRtk5vtJYaQKQ0o+UPPjO5F N1ugIxFF8eUXSdcANSr4y70vcjx4zcT5vhdWWPeE8g4GnkLuE4Ww+BCAGpzwPlk/KlH0 Suhmebuq28HaZdsOEmbHXmDtt4mjtFw56UeuM= MIME-Version: 1.0 Received: by 10.213.33.73 with SMTP id g9mr1951483ebd.46.1281717263909; Fri, 13 Aug 2010 09:34:23 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.213.10.196 with HTTP; Fri, 13 Aug 2010 09:34:23 -0700 (PDT) In-Reply-To: <4C656275.30201@FreeBSD.org> References: <4C656275.30201@FreeBSD.org> Date: Fri, 13 Aug 2010 16:34:23 +0000 X-Google-Sender-Auth: gi8TCJ48ny02c6HUAhEHl581Qds Message-ID: From: mdf@FreeBSD.org To: John Baldwin , freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 16:34:25 -0000 On Fri, Aug 13, 2010 at 3:19 PM, John Baldwin wrote: > mdf@FreeBSD.org wrote: >> >> Looking over the arch-specific definitions, using uintptr_t and size_t >> would not affect the actual width of these sizes. =A0However, it would >> simplify e.g. conformant printf(9) statements, since there is an >> approved specifier for size_t and, while there isn't one for >> uintptr_t, ptrdiff_t is pretty close (Bruce, is there a better >> specifier)? >> >> Admittedly, this isn't the simplest of undertakings, as there are 590 >> instances of vm_size_t in the FreeBSD source code and 3887 of >> vm_offset_t. >> >> Has this proposal made the rounds before and been shot down for some >> reason? > > Hmm, I suspect vm_offset_t predates uintptr_t. =A0I'm not sure the churn = is > really worth the effort involved especially as regards conflicts in futur= e > MFC's, etc. =A0You also forgot vm_ooffset_t -> off_t. =A0However, how oft= en are > vm_*_t values printed outside of temporary debug statements? They shouldn= 't > be used in userland, so I'm not sure if there are enough printf() > invocations to really justify the churn. Well, it wasn't just about printf, but that's one (potential) justification that Bruce shot down. :-) My thinking was also that the types did predate the C99 "standard" types that represent the same things. There seem to be fewer typedef's in FreeBSD than e.g. AIX; for example, cpu identifiers are alternately int or u_int, but there's no cpu_t type that is guaranteed wide enough to hold mp_maxid. short would be sufficient for the near future and also allows for -1 to represent an out-of-band value. cpu_t is just one example of a "missing" typedef, though I can't recall any others at the moment. Given that, I was under the vague assumption that FreeBSD preferred to use base types where possible instead of typedefs, as a project. This discussion has been very helpful for me to learn from. Thanks, matthew