[PATCH] print format correctness for uid, gid, pid, mode in "util-linux/ipcs.c"

Joe Krahn krahn at niehs.nih.gov
Thu Mar 6 19:25:48 UTC 2008


walter harms wrote:
> 
> Joe Krahn wrote:
>> In "util-linux/ipcs.c", gid, uid, pid and mode values are all assumed to be default-size ints. I
>> have patched the formats to use long ints, and cast all arguments to longs. This seems to be the
>> common approach. The one exception is that I cast arguments with (mode&0777) as default-size ints.
>>
>> In reality, most busybox target platforms have the same size for int and long-int, but there are
>> some 64-bit platforms where these values really are larger than default ints. The only way to be
>> exact is to use macros as in <inttypes.h>, which gets rather ugly. OTOH, that approach might avoid
>> unnecessary casting in some case, and might really be a better fit for the very-light-weight design
>> goal.
>>
> 
> Hi Joe,
> your comment is correct: some system have a funny long/int ratio.
> 
> the ipcs stuff if only useful in linux context and the current code defines
> e.g. uid_t == __kernel_uid32_t == unsigned int
> while   __kernel_mode_t ==   unsigned short
> long is used only with off_t and time_t
> 
> IMHO int is a save bet (what may change in future !). Do you have architecture
> where this is a really wrong assumption ?
> 
> ntl: we should use %u more often

Broadcom's gcc-3.0 MIPS compilers uses long signed int for uid and
gid in struct ipc_perm. That is also why I thought signed formats were
OK (i.e. some people write -2 as the nobody uid), but in fact Linux
defines them as unsigned. Does the signedness actually depend on the platform?

I just checked and found that later Broadcom GCC versions are not this
way, so this is an unusual case. But, I am stuck using 3.0 for
compatibility with some binary-only object files.

Maybe the safe approach would be to add (unsigned int) casts, and leave
the format strings alone.

Joe






More information about the busybox mailing list