RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t

[mdf at FreeBSD.org]

On Fri, Aug 13, 2010 at 3:19 PM, John Baldwin <jhb at freebsd.org> wrote:
> mdf at 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.

Thanks,
matthew