Date: Mon, 16 Aug 2010 16:01:03 -0400 From: John Baldwin <jhb@freebsd.org> To: mdf@freebsd.org Cc: freebsd-arch@freebsd.org Subject: Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t Message-ID: <201008161601.04203.jhb@freebsd.org> In-Reply-To: <AANLkTimjBQ9OsRfSFO0AWOaETqWCy9Hug7BoViBH1N8x@mail.gmail.com> References: <AANLkTik_2pXA1LP9dq-iOLkFrQBG7jP=4yUXBjtDOBF3@mail.gmail.com> <4C656275.30201@FreeBSD.org> <AANLkTimjBQ9OsRfSFO0AWOaETqWCy9Hug7BoViBH1N8x@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, August 13, 2010 12:34:23 pm mdf@freebsd.org wrote: > 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. 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. > > 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. FreeBSD is hesitant to add new foo_t typedefs. style(9) basically forbids adding ones unless they are mandated by a standard. I think in the case of the VM types, it is case of preserving the "feel" of the Mach VM code. For better or worse large sweeps of "style" fixes are generally not encouraged either, and I think this would fall into that category. The cpuid type thing is quite a sordid affair at the moment. The canonical type for CPU IDs is actually a u_char (see td_oncpu) with a NOCPU constant (0xff) used to denote an out-of-band value. Some newer APIs use 'int' instead I think due to making room for larger CPU ID values than fit in a u_char. I would probably settle on 'int' myself and not bother with a 'short'. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008161601.04203.jhb>