Re: Can id_t divergence be addressed for future ports?
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.
In general, I would use the same size as kernel for new ports.
According to Posix 2008:
id_t
Used as a general identifier;
can be used to contain at least a pid_t, uid_t, or gid_t.
The only drawback will be difference of the proper printf format string.
And carefull implementation of getpriority/setpriority,
they are declared as using id_t in glibc (<sys/resource.h>),
but syscall interface uses just int.
It belongs us into question: why it is 64bit under kernel, iff the only
interface which should use it uses 32bit anyway.
Does someone know if there's a justification for using uint32_t other
than binary compatibility?
I am aware only of binary compatibility.
Petr
Reply to: