Patch to fix some simple compilation warnings
rdiezmail-rtems at yahoo.de
Fri Aug 2 19:34:00 UTC 2013
> * Should R. be the first name in the commit? Or can we use
> your full first name?
I'd be happy with "R. Diez". I haven't published much info about myself yet, but here is my "home page" if you want to know more about my hackerspace or about what I'm doing with the Arduino Due:
> * dirutils.c: I don't use cexp but know it is a shell in which you
> can invoke C methods. The methods you made static appear
> to all have one of more char * arguments which makes me
> suspect they may be helpers to be invoked from cexp.
> Do you use cexp? Can they still be invoked if static?
I don't use cexp, I don't even know what that is. Those routines look like some debug helpers, they just print messages with printf().
> The names are pretty common so I am prone to approve the
> patch if we don't hear from any cexp users. But if someone
> complains IMO we should remove the static and prepend cexp_
> to the name to avoid putting such common names into the
> global symbol space.
Yes, but then you would have to provide a header file, or you'll get compilation warnings. I haven't seen any other code that references them outside that module.
> * rtems-rfs-format.c: Chris Johns should comment.
Do you mean I should find out who Chris Johns is and contact him?
The patch is really simple and fixes straightforward compilation warnings. I reckon it would take a couple of minutes for you to rebuild all once and fix all the warnings.
There are a couple of them that are not that easy though:
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=]
This probably an issue in newlib (the way inttypes.h defines PRIo32), I'll see if I can raise it with them.
There are also warnings about _gettimeofday_r and the like. I'm not sure RTEMS should export these symbols, as there does not seem to be a header file that exports them as functions.
There are also warnings about "rtems_interrupt_disable", look at this file:
That file is testing that "rtems_interrupt_disable" is both provided as a macro and as a function (!). I don't think that's a good idea, and GCC tends to agree, hence the warnings. 8-)
More information about the devel