El 6 de febrer de 2012 7:35, Petr Salinger <petr.salin...@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 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOfDtXOackQ5LpngdOrPW-ptFz=BxaGp0hGw9nU=sfy_jvg...@mail.gmail.com
