Hallo Ralf: I'm an RTEMS newbie, but nevertheless I've been trying to fix the following compilation warning:
rtems/c/src/../../cpukit/libfs/src/rfs/rtems-rfs-rtems.c:479:13: warning: format '%lo' expects argument of type 'long unsigned int', but argument 3 has type 'mode_t' [-Wformat=] The same warning occurs here too, but after a patch I sent, you may need to define HAVE_CEXP in that file to make it come up: c/src/../../cpukit/libfs/src/nfsclient/src/dirutils.c:142:5: warning: format '%lo' expects argument of type 'long unsigned int', but argument 6 has type 'mode_t' [-Wformat=] I've been digging around, and the reason is that newlib prefers 'long' over 'int' for the int32_t type. In newlib (at least as built for RTEMS), file inttypes.h, there are these definitions: #define PRIo32 __PRI32(o) ... #if __have_long32 #define __PRI32(x) __STRINGIFY(l##x) ... That means that PRIOo32 ends up as "lx", which means a "long integer". I thought you may be able to help, because your name appears at the top of the file, and because you provided in the distant past a patch to newlib to do exactly that: http://sourceware.org/ml/newlib/2005/msg00824.html By the way, could you detail what those "subtle issues" are? This same issue has been discussed in the newlib mailing list again, and it looks like that decision should actually have been reverted: http://cygwin.com/ml/cygwin/2009-03/msg00492.html In the particular case above: printf ("rtems-rfs-rtems: fchmod: in: ino:%" PRId32 " mode:%06" PRIomode_t "\n", ino, mode); I found that chaning "mode" to "(long)mode" above fixes the warning. However, it's probably not a good idea to always use "long" there. Are there any other constants in the same fashion as PRIOo32 etc. for that kind of typecast? As an alternative, we could do the same as Linux/GLIBC/etc. (I must admit I haven't checked this in detail yet) and map int32_t to 'int' instead of 'long'. Before I dig even deeper, I thought I could ask you. In your opinion, what would be the best way to fix that compilation warning? Thanks in advance, rdiez _______________________________________________ rtems-devel mailing list [email protected] http://www.rtems.org/mailman/listinfo/rtems-devel
