Open roelandjansen opened 5 years ago
Interesting. I wrote it to MSC specs and it built without warnings or errors using the C compiler in /bin. What warnings did your lint see?
I am trying to use tools in the /bin directory for now to keep the build process DOS/MOS based.
note that this is against gcc which is not your used compiler. It's just for the future. I am inclined to believe that at some point in time a cross-compiler chain could be used for the stuff.
src/pcmos386v501/SOURCES/src/latest/SNGEN.C: (in function main) src/pcmos386v501/SOURCES/src/latest/SNGEN.C:31:2: Return value (type time_t) ignored: time(&tseed) Result returned by function call is not used. If this is intended, can cast result to (void) to eliminate message. (Use -retvalother to inhibit warning) src/pcmos386v501/SOURCES/src/latest/SNGEN.C:32:8: Function srand expects arg 1 to be unsigned int gets int: (int)tseed To ignore signs in type comparisons use +ignoresigns src/pcmos386v501/SOURCES/src/latest/SNGEN.C:36:2: Unrecognized identifier: itoa Identifier used in code has not been declared. (Use -unrecog to inhibit warning) src/pcmos386v501/SOURCES/src/latest/SNGEN.C:40:7: Value tmpbuf[] used before definition An rvalue is used that may not be initialized to a value on some execution path. (Use -usedef to inhibit warning) src/pcmos386v501/SOURCES/src/latest/SNGEN.C:48:2: Return value (type int) ignored: fclose(serfil) Result returned by function call is not used. If this is intended, can cast result to (void) to eliminate message. (Use -retvalint to inhibit warning) src/pcmos386v501/SOURCES/src/latest/SNGEN.C:61:2: Return value (type int) ignored: fclose(regfil) src/pcmos386v501/SOURCES/src/latest/SNGEN.C:13:6: Variable counts declared but not used A variable is declared but never used. Use /@unused@/ in front of declaration to suppress message. (Use -varuse to inhibit warning)
Finished checking --- 7 code warnings
(and yes, again -- differences in compilers !)
and I also have been looking for some tools that run under linux that can do some checking against the assembly code. But as stated in the first comment -- it's future work.
Thanks @roelandjansen. I will clean up the warnings I can that don't break the code and submit a patch. I'll also run any code I write through splint or similar prior to testing/submitting.
I know itoa is not compatible with *nix, so that can't be fixed without writing a new itoa. The others look like teasing out casts on function returns and an int vs. unsigned int.
Thanks for the heads-up.
See #74
when I merged #72 splint generated a few warnings.
I'll add the issue that we should use lint-checkers against the code in the future and fix the warnings we encounter. For this moment it's good enough.
I could fix it myself but then it would be against gcc's syntax and since there is not an unified build env (yet?) and/or cross compile etc etc.
(in the future automatic tests/builds et al could be in place)
For now: I'll leave this as a TODO