[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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
#define __CLOCK_T_TYPE          __S32_TYPE

#if defined(__i386__) || defined(__amd64__)
#define __TIME_T_TYPE           __SLONGWORD_TYPE
#elif defined(__powerpc__) && !defined(__LP64__)
#define __TIME_T_TYPE           __S32_TYPE
#define __TIME_T_TYPE           __S64_TYPE

Robert Millan

Reply to: