Note that sometimes you'll have to postprocess that output further, by
piping it through "expand -i", since some leading TABs can get through.
Usually they're in macro definitions or strings, and should be converted
anyhow.
</p>
<h2>
<ahref="types">C types</a>
</h2>
<p>
Use the right type.
</p>
<h3>Scalars</h3>
<ul><li>If you're using "int" or "long", odds are good that there's a better type.</li><li>If a variable is counting something, be sure to declare it with an
unsigned type.</li><li>If it's memory-size-related, use size_t (use ssize_t only if required).</li><li>If it's file-size related, use uintmax_t, or maybe off_t.</li><li>If it's file-offset related (i.e., signed), use off_t.</li><li>If it's just counting small numbers use "unsigned int";
(on all but oddball embedded systems, you can assume that that
type is at least four bytes wide).</li><li>If a variable has boolean semantics, give it the "bool" type
and use the corresponding "true" and "false" macros. It's ok
to include <stdbool.h>, since libvirt's use of gnulib ensures
that it exists and is usable.</li><li>In the unusual event that you require a specific width, use a
standard type like int32_t, uint32_t, uint64_t, etc.</li><li>While using "bool" is good for readability, it comes with minor caveats:
<ul><li>Don't use "bool" in places where the type size must be constant across
all systems, like public interfaces and on-the-wire protocols. Note
that it would be possible (albeit wasteful) to use "bool" in libvirt's
logical wire protocol, since XDR maps that to its lower-level bool_t
type, which *is* fixed-size.</li><li>Don't compare a bool variable against the literal, "true",
since a value with a logical non-false value need not be "1".
