Patch to fix some simple compilation warnings

[R. Diez]

> * 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:

https://ssl.devtal.de/wiki/Benutzer:Rdiez


> * 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:

http://git.rtems.org/rtems/tree/testsuites/sptests/sp37/init.c

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-)


Cheers,
   rdiez