Re: Can id_t divergence be addressed for future ports?
El 6 de febrer de 2012 7:35, Petr Salinger <Petr.Salinger@seznam.cz> ha escrit:
>> 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.
I agree... diverging from kernel types is a PITA. We'll have to check
that no user-exposed ABI is using any of the diverged types.
Would a generic s/id_t/int64_t/g in kernel headers be a sane thing to do?
> The only drawback will be difference of the proper printf format string.
Uhm that's annoying, as it will break code that uses -Werror. I'd
rather have to live with this than with risk of ABI breakage, though.
> It belongs us into question: why it is 64bit under kernel, iff the only
> interface which should use it uses 32bit anyway.
Signedness. As pid_t is signed, id_t must be able to hold negative
integers. But if id_t were int32_t, then it can't hold 32-bit
unsigned integers (uid_t).
GNU/Linux has the same problem. I don't know why it uses int32_t, but
it looks like either a mistake, or an implicit limit in the number of
users (which would be kernel-dependant, we shouldn't assume such thing
IMHO).
Are you ok with adjusting typesizes.h to use int64_t for new ports?
Btw, do you have some comments on clock_t and time_t? This is what we have now:
#if defined(__arm__) || defined(__powerpc__)
#define __CLOCK_T_TYPE __U32_TYPE
#elif defined(__i386__)
/* clock_t is unsigned in FreeBSD/i386, but it's too late to fix that now... */
#define __CLOCK_T_TYPE __S32_TYPE
#else
#define __CLOCK_T_TYPE __S32_TYPE
#endif
#if defined(__i386__) || defined(__amd64__)
#define __TIME_T_TYPE __SLONGWORD_TYPE
#elif defined(__powerpc__) && !defined(__LP64__)
#define __TIME_T_TYPE __S32_TYPE
#else
#define __TIME_T_TYPE __S64_TYPE
#endif
--
Robert Millan
Reply to: