* Pekka Enberg <penberg@xxxxxxxxxx> wrote:
> We switched to u64 and friends for two reasons: (1) using uint*_t turned out
> to be painful when using kernel headers (e.g., mptables, e820, etc.) and (2)
> we want to be as close as possible to the coding style of tools/perf to be
> able to reuse their code in the future.
3)
uint*_t caused frequent type mismatches and breakages with format strings if
accidentally an uint*_t was stuck into a regular printf format - it would
trigger a warning only on 64-bit or only on 32-bit systems, causing frequent
flux. This is not a very good data type model.
4)
uint*_t also causes absolute brain-damaged printf format hacks like:
fprintf(stderr, "%s: %" PRIu64 " %" PRIu64 " %" PRIu64 "\n",
event_name(counter), count[0], count[1], count[2]);
instead of the much cleaner:
fprintf(stderr, "%s: %Lu %Lu %Lu\n",
event_name(counter), count[0], count[1], count[2]);
So we can use uint*_t where absolutely necessary due to external ABI
constraints, but otherwise it's discouraged for tools/kvm/ internal code.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
