Joe Krahn wrote: > 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. >
Hi Joe, i quick dive into posix shows that they do not define the sign. The examples do a cast to (unsigned long). I thing your later versions confirm that the earlier version is crap. The whole stuff should come as part of you OS, gcc does not have anything to do with it. You can compare that .h with other .h from the same linux version to identify the culprit. ntl: it should not hurt you will see -1 as large number (if requested) this should not break the system (but perhaps some unwary scripts). re, wh _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
