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