> * 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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
