Lionel_Debroux lionel_debroux@yahoo.fr writes:
tools/fnt2fon is flagged in the janitorial page "IgnoredReturnValues". This page is outdated, but its content is still valid for fnt2fon, which ignores a number of return values.
I don't think that's worth fixing, the warnings are essentially useless, it just makes the code uglier. There may be a few legitimate errors in there, like checking the fopen() result, and those could be fixed; but please don't add checking to every call that gcc complains about.
tools/fnt2fon is flagged in the janitorial page "IgnoredReturnValues". This page is outdated, but its content is still valid for fnt2fon, which ignores a number of return values.
I don't think that's worth fixing, the warnings are essentially useless, it just makes the code uglier.
OK, I won't do that again :-)
There may be a few legitimate errors in there, like checking the fopen() result, and those could be fixed;
There are indeed several legitimate errors, such as: * not checking the fopen() result; * the current input file (fp) is not always closed when exiting; * the atexit() and signal() calls are placed too late in the program, and their return values are not checked; * I've just seen on Michael Stefaniuc's potential issues page that Smatch reports a memory leak, and it looks like a legitimate error.
but please don't add checking to every call that gcc complains about.
OK. Actually, it's not GCC, but splint, since the headers on my SimplyMEPIS 6.x/Debian box don't contain __attribute__((warn_unused_result)). Vincent Béron has certainly used another distro (Fedora-type ?) to get GCC to complain about those calls.
Regards, Lionel Debroux.
Lionel_Debroux lionel_debroux@yahoo.fr writes:
- the current input file (fp) is not always closed when exiting;
Closing the input on exit is useless.
- the atexit() and signal() calls are placed too late in the program,
and their return values are not checked;
Their return value is irrelevant, they won't fail, and if they do you can't do anything useful about it anyway.
- I've just seen on Michael Stefaniuc's potential issues page that
Smatch reports a memory leak, and it looks like a legitimate error.
Memory leaks in a short lived tool like fnt2fon don't really matter.
I'm not saying these things can't be fixed, but the effort has to be proportional to the results, and in the case of something like fnt2fon it's most likely not worth it. It's better to spend time fixing bugs in the dlls.
-
Alexandre Julliard -
Lionel_Debroux