On 24-Mar-2014 16:28, Johan Engelen wrote:
On 25-3-2014 0:20, mathog wrote:
On 22-Mar-2014 06:16, su_v wrote:
-Wno-error=self-assignmore errors:
../../src/libuemf/uwmf_endian.c:285:10: error: explicitly assigning a variable of type 'int' to itself [-Werror,-Wself-assign]
Sometimes you can't win.
The line with the warning is the second one below:
void U_WMRCORE_SIZE16_swap(char *record, int torev){ torev = torev; // shuts up compiler warnings about unused parameters U_swap4(record, 1); /* Size16_4 is at offset 0 in U_METARECORD */ }
where this is one of those situations where there are a large number of functions all use the same argument list, but some of them don't actually use some of the arguments. The
torev = torevtrick is one way to silence the "unused argument" warning in gcc and last time I checked it worked for several other compilers as well, like Sun's compiler. Apparently not for clang though. Note this is in a C module, so the C++ syntax to indicate an unused argument will not work. AFAIK the C language specification provides no standard way to eliminate this warning or its evil twin "statement with no effect", which is what you get if you try to finesse this situation with:
(void) torev;Note, the other similar clang warnings are all for the same thing.
The problem is that torev = torev is not instructive as to what it is doing. [*]
Really? To me it clearly does nothing at all! When the programmer wonders why there is a line that does nothing at all they can read the comment I always try to include next to it.
I do wish that the C language, as opposed to a few C compiler extensions, supported the C++ syntax for ignoring function arguments, but sadly it does not.
The self-assignment may actually have side-effects for C++ objects, so for us such a line looks very suspicious.
Understood, but finding it in a .c file should tell you that it has nothing to do with C++ objects.
A much better way (and more generally accepted I believe) is what I already did in a number of places in libuemf: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13182
Unfortunately, as I indicated above, that is not actually any better, as it generates
"statement with no effect"
warnings with other compilers and/or compiler versions.
I don't have clang, nor do I have Markus's scanner, nor do I have any of the Microsoft compilers, if anybody is using those on Windows. If somebody who does have these can send me:
1. the syntax that suppresses all warnings associated with an unused function argument 2. the preprocessor Macro that identifies that environment
I will set up the appropriate tests in one of the header files so that libUEMF compiles silently in all of our build environments. Until, most likely, we hit some future compiler or compiler revision that wants yet another syntax. My experience has been that it is basically impossible to write anything more than a toy program that will continue to build cleanly forever into the future, since the compiler developers are always adding new warnings, and unlike error messages, warning messages often do not actually indicate bugs. As in this case.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech