Date: Fri, 13 Aug 2010 16:34:23 +0000 From: mdf@FreeBSD.org To: John Baldwin <jhb@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t Message-ID: <AANLkTimjBQ9OsRfSFO0AWOaETqWCy9Hug7BoViBH1N8x@mail.gmail.com> In-Reply-To: <4C656275.30201@FreeBSD.org> References: <AANLkTik_2pXA1LP9dq-iOLkFrQBG7jP=4yUXBjtDOBF3@mail.gmail.com> <4C656275.30201@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 13, 2010 at 3:19 PM, John Baldwin <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimjBQ9OsRfSFO0AWOaETqWCy9Hug7BoViBH1N8x>