Fix traffic analyzer developer build

[Jeremy Allison]

On Fri, Mar 19, 2010 at 03:00:09PM +0100, Holger Hetterich wrote:
> Hi Jeremy, thank you for looking at this!
> 
> With the argumentation used above, I could cast almost all
> ints in the asprintf format, because most of the values will
> never be negative. However it was my original intention to not
> have to cast all the values inside the asprintf format. :)

I prefer to keep variables as abstract types, and cast them
when being used in an asprintf-type function.

> Also, nearly none of the values will ever  be in the range where
> unsigned/signed does matter. The only exception I see is theoretically
> the write/pwrite/read/pread call, that returns a size_t as the
> number of bytes that have been transferred. And even there
> it's unlikely I'll hit the borders. 
> 
> So in this patch, I am using a size_t for write,read,pread,pwrite,
> and cast it to unsigned int.

The way I've been thinking about this in Samba
has changed over the years. Here's what I do now:

Use the internal abstract types returned from
system functions. e.g. use "size_t" for returns
from strlen, not "int" or "unsigned int".
Use abstract types internally when you need
to hide the difference between compiling on
64 or 32 bit systems. That's why pread etc.
return ssize_t, and take an offset of off_t,
because you don't know the native size of
values at this point.

Only use types of a known size when you
are interfacing with functions outside
the program (i.e. an asprintf output,
or writing out a field within a binary
data element which has to have a known
size). That's when you need to do the
case of (uid_t) -> (unsigned int) and
use a %u value, etc. etc. Keep a uid
(for example) inside the program as
a uid_t. Convert on read/write to
external storage (a printf counts
in this example).

So our macro's SIVAL take a uint32_t,
not a size_t or unsigned int. At the
point we're using SIVAL we absolutely
*need to know* the size we're dealing with.

Jeremy.