Can id_t divergence be addressed for future ports?

[Robert Millan <rmh@debian.org>]

There's a divergence in id_t definition between Glibc and kfreebsd headers:

- Glibc defines id_t as uint32_t (on all architectures)

- kFreeBSD defines id_t as int64_t (on all architectures)

Glibc defines id_t in <bits/typesizes.h> which allows kernel ports to
define it as they please. Unfortunately even if we find that there's
no justification for diverging from FreeBSD, we can't change existing
ports (i386 and amd64).

The question remains on whether future ports should keep using
uint32_t or switch to int64_t.

Does someone know if there's a justification for using uint32_t other
than binary compatibility?

(I ask this now because I'm preparing to discuss with upstream about
patching their kernel headers for __GLIBC__ && !_KERNEL compatibility,
and I need to know if id_t will have to diverge on all architectures
before making a proposal)

-- 
Robert Millan