DragonFly BSD
DragonFly users List (threaded) for 2005-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Help with size_t

From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Wed, 6 Apr 2005 19:02:05 +0200
Mail-followup-to: users@crater.dragonflybsd.org

On Wed, Apr 06, 2005 at 08:20:00AM -0700, walt wrote:
> To pick a random instance, in libkinfo:
> size_t len = sizeof(*cputime);
> By wandering through /usr/include I can find that size_t works out
> to be an 'int', which makes good sense.  The number of bytes in

It's an unsigned int on IA32, it would be a long e.g. on Alpha
and it would be a long long on Windows' 64 bit edition.

> *cputime is going to be a small integer number, certainly not more
> than 128, probably less.
> So, my real question is:  why go thru the dance of using 'size_t' when
> I know for sure that an 'int' is going to work perfectly?  What is the
> motivation for this confusing chain of typedefs?

size_t is there as the natural length type. Read again. If you want to
pass an argument to any memory related functions, it should be size_t
or the signed ssize_t. Functions related to files take an off_t, with
just the same argument.

Sure, in this specific instance, you know that cputime is small, but
it still makes sense because it makes the functions more uniform.
For example, there isn't much a reason why more than 2^31 bytes could
be needed for the process table in the near future on a 64 bit OS.

This isn't some wiered magic decision, it is common practise for all
interfaces and those which don't use it will be fixed.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]