These aggressive warnings seem to have appeared in the most recent release of Xcode.
There does indeed seem to be a problem building Catalina under more recent versions of OSX and XCode. My old Hackintosh was based on Snow Leopard, so I just built myself a new one based on Mountain Lion and it is picking up errors that previous versions compiled quite happily.
That part I can understand - but it is also spitting out huge numbers of very aggressive warnings for things that are in fact perfectly valid and commonplace C code, so I can't see how I can fix those - perhaps the answer is to simply disable the warnings (as you have done for gcc). I really have a bit of an issue with some of these messages - they make you think you may be doing something wrong, when in fact all you are doing is taking advantage of some perfectly valid C language features.
Anyway, I have fixed all the errors that were preventing Catalina from compiling under OSX with more recent versions of Xcode - I will post an errata file for OSX shortly.
When you build on OSX isn't the compilation done by Clang/LLVM ?
A far as I understand Clang can produce a lot of warnings for potentially dangerous and commonly bug prone uses of C/C++ language features even if those features are being used in a correct and useful way.
A typical example is the accidental use of "=" instead of "==" in the conditional expression of an "if". A common source of errors in C. That warning can be suppressed by using double brackets around the conditional like so: "if (( a = someFunc(x) ))". Conversely Clang will complain if you wrap the extra pair of brackets around a conditional using "==".
Here is a wonderful presentation by Chandler Carruth of the Clang team at Google explaining what Clang is up to and how it is trying to defend C/C++ programmers from Murphy's Law.
When you build on OSX isn't the compilation done by Clang/LLVM ?
Aha! That would explain why when I go "gcc --version" I get some claptrap about clang and LLVM - it would appear that even though I installed gcc I'm not actually compiling with gcc at all? How confusement!
Anyway, I have a version of Catalina that now compiles on OSX no matter which compiler you use, so I will post it shortly.
I am not interested in someone lecturing me on the many failings of C++ and how to avoid them. To me, the answer is obvious - just avoid C++
Perhaps. But a lot of those "dangerous" language features are in C anyway.
I accept that there are some C constructs that novices routinely get wrong, and all good compilers warn you that the consequence may not be what you intended.
But some of the Xcode/clang/LLVM warnings are a bit over the top - they suggest you change your programs in ways that would make them compile, but then execute incorrectly - when there was in fact nothing wrong with the program in the first place!
Xcode/clang/LLVM warnings are a bit over the top - they suggest you change your programs in ways that would make them compile, but then execute incorrectly
Interesting. Can you give us some examples of code that produces such warnings? I started playing with Clang a while back and haven't come across any yet.
Interesting. Can you give us some examples of code that produces such warnings? I started playing with Clang a while back and haven't come across any yet.
I think you mentioned one previously. Common C usage is to assign the result of a function to a variable, then test that the variable is true before proceeding. Something like:
if (result = function(a)) {
... do something ...
}
This is both correct usage and so common as to be quite unremarkable. Fair enough to throw a warning about whether "==" is meant instead of "=", but the clang warning message implies that double parentheses are an appropriate solution. But this "double parenthesis" stuff is not in accordance with any C or C++ language specification that I am aware of, and in some cases could conflict badly with the "comma operator" in C. To understand this, try compiling and running the following program:
#include <stdarg.h>
void print(int arg1, ...)
{
va_list ap;
int i;
va_start(ap, arg1);
for (i = arg1; i >= 0; i = va_arg(ap, int))
printf("%d ", i);
va_end(ap);
putchar('\n');
}
int main(void)
{
printf("case 1: "); print(0, 2, 14, 84, 97, 15, 24, 48, -1); // single parenthesis
printf("case 2: "); print((0, 2, 14, 84, 97, 15, 24, 48, -1)); // double parentheses
return 0;
}
Now, I've not thought this though in detail, but it would appear to me that suggesting "double parentheses" as a solution could in fact lead to bigger, more subtle, and much harder to find problems.
The alternative to double parentheses suggested is to replace the "=" with "==". This is certainly be wrong - it would stop the warning appearing, but will result in an erroneous program.
Basically, it is reasonable for a compiler to throw a warning, but not to suggest solutions that may be erroneous. That is a bridge too far!
All very interesting stuff, and clang/LLVM is obviously a much more sophisticated compiler than plain old gcc - but if users really require that level of sophistication to prevent them making such basic errors, it is probably a good indicator that they are programming in the wrong language.
Clearly clang is telling me that those extra braces are almost certainly not what is intended. Which seems to be quite reasonable in this case.
Am I missing a point or do you have a better example?
Odd - I don't get that warning when I compile it (nor would I expect to, since it is perfectly valid C). I don't have access to my Hackintosh at the moment so I can't check - but I think I am using clang 4.2. In any case, I think you can easily tweak the list of expressions to not be "unused" and therefore achieve the same result:
int a,b,c;
printf("case 1: "); print(a=1,b=2,c=3, -1); // single parenthesis
printf("case 2: "); print((a=1,b=2,c=3, -1)); // double parentheses
So yes, I think you are missing the point. Double parenthesis can mean something in C as a consequence of various other language rules - but this meaning is not what clang suggests you use them for, which is essentially to disable a warning that I think should never really have been there in the first place (at least not as the default - fair enough if you specifically ask for such warnings to be enabled).
In any case, C already provides a mechanism for such compiler-specific behavior (#pragma). A pragma is a much clearer way of telling both the compiler and the reader that the code is in fact correct, no matter how strange it may appear. Why does clang need another mechanism, and why choose one that seems bound to confuse novice C programmers even further?
That last example does not give me any errors or warnings in clang even with -Wall. Seems everything is working fine.
I don't see how this is going to confuse novice users. In fact the whole clang idea is to warn of typical mistakes and typeos novice make.
In that video about clang I linked to Caruth actually says they want to be as careful and conservative with warnings and suggestions. So far I have yet to find anything naff going on in what they have done.
Pragmas are ugly.
P.S. I have just realized. Clang is not worrying about brackets in your first example. The warning is about unused expression results, which is totally OK with me as it is true and redundant and almost certainly not what you meant to write. The deal with double bracketing should only come into lay when there is a possible confusion between "=" and "==".
That last example does not give me any errors or warnings in clang even with -Wall. Seems everything is working fine.
I don't see how this is going to confuse novice users. In fact the whole clang idea is to warn of typical mistakes and typeos novice make.
In that video about clang I linked to Caruth actually says they want to be as careful and conservative with warnings and suggestions. So far I have yet to find anything naff going on in what they have done.
Pragmas are ugly.
P.S. I have just realized. Clang is not worrying about brackets in your first example. The warning is about unused expression results, which is totally OK with me as it is true and redundant and almost certainly not what you meant to write. The deal with double bracketing should only come into lay when there is a possible confusion between "=" and "==".
Hi Heater,
Clang is a great compiler and I generally have no problems with it apart from the fact that it generates so many warning for perfectly valid C code, which will confuse novice programmers and encourage both novices and experienced programmers alike to turn off warnings altogether, because they actually obscure the real problems. This kind of spoils the whole point of having them!
And in some cases the warning are just plain dumb, such as the double parentheses case. Suggesting to novice users that they use double parentheses to sort out a problem they probably don't even understand does not solve the original problem at all. Instead it will just lead them to assume that the language requires you to use double parentheses, as if this construct meant something in the C language. It does not. Or rather, it does (as I have demonstrated) - but not what Clang implies that they mean!
In summary, it's a silly solution that does not address the underlying problem, and is likely to cause even more confusion in some cases.
You may not like pragmas - I don't either - but they were designed to cope with situations just like this. So why introduce another solution, and one which is non-standard, and implemented only in a single compiler?
This is my main problem with C++ - it is a language riddled with poorly conceived attempts to sort out what are in fact fairly minor problems with C. The enduring popularity of C and the continuing decline in the popularity of C++ is the result.
Clang is a great compiler and I generally have no problems with it apart from the fact that it generates so many warning for perfectly valid C code, which will confuse novice programmers and encourage both novices and experienced programmers alike to turn off warnings altogether, because they actually obscure the real problems. This kind of spoils the whole point of having them!
And in some cases the warning are just plain dumb, such as the double parentheses case. Suggesting to novice users that they use double parentheses to sort out a problem they probably don't even understand does not solve the original problem at all. Instead it will just lead them to assume that the language requires you to use double parentheses, as if this construct meant something in the C language. It does not. Or rather, it does (as I have demonstrated) - but not what Clang implies that they mean!
In summary, it's a silly solution that does not address the underlying problem, and is likely to cause even more confusion in some cases.
You may not like pragmas - I don't either - but they were designed to cope with situations just like this. So why introduce another solution, and one which is non-standard, and implemented only in a single compiler?
This is my main problem with C++ - it is a language riddled with poorly conceived attempts to sort out what are in fact fairly minor problems with C. The enduring popularity of C and the continuing decline in the popularity of C++ is the result.
Ross.
I actually have no problem with the warning about use of = in an if statement but maybe that's because I learned not to do that a long time ago. I would instead code this as:
if ((a = foo()) != 0)
;
However, I do think clang is too aggressive about its warnings.
I don't understand the negativity toward clang's warnings. C offers plenty of syntactic possibilities for making silly little errors. Warnings are of course making comments on your perfectly valid code in an effort to prevent those silly errors and typeos. It's just that Clang has decided to have more of them.
The specific case of "=" and "==" in conditionals and double/single brackets seems quite reasonable to me. One could force the issue by using David's method but to my eye that looks messy.
I have yet to find Clang issuing a warning that I thought was excessive or wrong. I.e. would break my code if I got rid of it. Certainly nothing to make me want to turn warnings off.
Do you guys have an example of a warning you don't like?
P.S. The Clang guys did actually remove a couple of warnings in recent Clang versions after a lot of user feedback so perhaps you are seeing more warnings than I am.
I don't understand the negativity toward clang's warnings. C offers plenty of syntactic possibilities for making silly little errors. Warnings are of course making comments on your perfectly valid code in an effort to prevent those silly errors and typeos. It's just that Clang has decided to have more of them.
The specific case of "=" and "==" in conditionals and double/single brackets seems quite reasonable to me. One could force the issue by using David's method but to my eye that looks messy.
I have yet to find Clang issuing a warning that I thought was excessive or wrong. I.e. would brake my code if I got rid of it. Certainly nothing to make make want to turn warnings off.
Do you guys have an example of a warning you don't like?
P.S. The Clang guys did actually remove a couple of warnings in recent Clang versions after a lot of user feed back so perhaps you are seeing more warnings than I am.
Here are some warnings I got when trying to compile GCC:
../../../propgcc/binutils/gas/symbols.c:1705:32: error: while loop has empty body [-Werror,-Wempty-body]
while ((*p++ = *--q) != '\0');;
^
../../../propgcc/binutils/gas/symbols.c:1705:32: note: put the semicolon on a separate line to silence this warning
I don't like having the semi-colon on the same line as the while but it is legal syntax.
Here is another:
../../../propgcc/binutils/ld/ldmisc.c:364:46: error: adding 'bfd_boolean' (aka 'int') to a string does not append to the string
[-Werror,-Wstring-plus-int]
fprintf (fp, "%u%s", linenumber, ":" + done);
~~~~^~~~~~
../../../propgcc/binutils/ld/ldmisc.c:364:46: note: use array indexing to silence this warning
fprintf (fp, "%u%s", linenumber, ":" + done);
^
& [ ]
Again, this is perfectly legal although kind of odd. In my case, I wasn't allowed to "fix" the code to avoid these warnings because it is part of the standard gcc distribution. Also, gcc gets built with an option that considers all warnings to be errors do I can't just ignore them either. This forced me to supply additional options to turn off the warnings in order to get propgcc to build.
I think that the problem with huge numbers of warnings about things that are perfectly legal is that it tends to make people either turn off warnings entirely or miss warnings of constructs that are really wrong.
On the other hand, this more agressive version of Xcode actually found a bug in the standard gcc distribution:
../../../propgcc/gdb/bfd/bfdio.c:580:31: error: 'memset' call operates on objects of type 'struct stat' while the size is based on a
different type 'struct stat *' [-Werror,-Wsizeof-pointer-memaccess]
memset (statbuf, 0, sizeof (statbuf));
~~~~~~~ ^~~~~~~
../../../propgcc/gdb/bfd/bfdio.c:580:31: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number
of elements)?
memset (statbuf, 0, sizeof (statbuf));
It looks to me as though this should really be:
memset (statbuf, 0, sizeof (*statbuf));
This is for the following code and I believe it is really a bug in gcc:
I'm going to side with clang on the "while loop has empty" body warning. In your example you have two semi-colons following the while which is just dumb. Remove one of them and there is no more warning. (Mind you I now wonder why it says "loop has empty body" when a single semi-colon there is still a loop with an empty body)
I'm also going to side with clang on the adding integer to a string thing. That's just a nuts thing to do. Especially since if I add a line like that to a test program I have here it segfaults:
That "sizeof" thing is a classic. It's one that Chandler Caruth talks about in that clang presentation video. Seems clang has found thousands of those errors in all kinds of famous projects where they have been lurking for years.
I think that the problem with huge numbers of warnings about things that are perfectly legal is that it tends to make people either turn off warnings entirely or miss warnings of constructs that are really wrong.
I agree. And that is why clang has removed a couple of over enthusiastic warnings by default. I am not seeing lots of annoying warnings.
If GCC is written in a sloppy way that is hardly clang's fault.
There is a delicious irony in the way the excessive warnings that clang emits over GCC are being argued against here whilst at the same time we see bugs being discovered in GCC by clangs warnings!
I'm going to side with clang on the "while loop has empty" body warning. In your example you have two semi-colons following the while which is just dumb. Remove one of them and there is no more warning. (Mind you I now wonder why it says "loop has empty body" when a single semi-colon there is still a loop with an empty body)
I'm also going to side with clang on the adding integer to a string thing. That's just a nuts thing to do. Especially since if I add a line like that to a test program I have here it segfaults:
I think the idea is that if "done" is set to 1 then the colon is not printed. This should work even though it might be an odd way of writing it. If it's segfaulting for you then there is a bug in your compiler. :-)
That "sizeof" thing is a classic. It's one that Chandler Caruth talks about in that clang presentation video. Seems clang has found thousands of those errors in all kinds of famous projects where they have been lurking for years.
I agree. And that is why clang has removed a couple of over enthusiastic warnings by default. I am not seeing lots of annoying warnings.
If GCC is written in a sloppy way that is hardly clang's fault.
There is a delicious irony in the way the excessive warnings that clang emits over GCC are being argued against here whilst at the same time we see bugs being discovered in GCC by clangs warnings!
So, any better examples of "wrong" warnings?
I'm not really arguing that they are "wrong". If it was my code I'd just fix them. The problem is that it's part of the standard GCC distribution so you either have to "fix" these warnings with every release or get the fixes pushed upstream. For now we figured it was best just to turn off those specific warnings. I did fix the sizeof bug though.
OK, I looked at that string plus integer thing again.
Seems that what clang's warning is suggesting is that it is written as:
&":"[done]
Which is even more sick. It looks horrible and conceptually we are indexing and array with what is intended to be a boolean. Gak!
But I would keep the warning as it is pointing out that you have written a really horrible piece of code.
The problem is that it's part of the standard GCC distribution
It has been said that the arrival of clang caused a spurt of rapid developments and improvements in GCC. Something about having to compete with the new kid on the block.
Perhaps clangs warnings will also spur he GCC guys to clean up their code !
It has been said that the arrival of clang cause a spurt of rapid developments and improvements in GCC. Something about having to compete with the new kid on the block.
Perhaps clangs warnings will also spur he GCC guys to clean up their code !
I don't understand the negativity toward clang's warnings.
I'm with David on this one. I have a large amount of perfectly legal C code which spits out a huge number of silly warnings when compiled under clang. It also spits out a few legitimate errors that gcc didn't catch, so that's a good thing - but these were completely obvious and trivial errors that took about 2 minutes to fix, whereas I have now spent many hours trying to address all the other warnings, and still have many left to go. Each one requires me to verify that the code is legal (which it is) and is working correctly (which it is). Even so, under clang I have no alternative but to change the code to prevent the warning - and of course every time I change the code I have to test it to make sure I have not made a silly typo and accidentally introduced a bug!
This has taken so much time that I have now decided to abandon thew whole effort and instead disable the warning altogether. So the whole thing has been completely counterproductive, The clang compiler seems to think it's job is to police programming style in addition to syntax and semantics. It's infuriating!
I'm not going to be convinced until I find a clang warning that annoys me or is actually silly. I have to ask again, do you have an example of such warnings?
Of course those warnings are in perfectly legal C code, that is why they are warnings and not errors.
...under clang I have no alternative but to change the code to prevent the warning
Well, you can turn of individual warning types with a command line switch. For example:
The clang compiler seems to think it's job is to police programming style in addition to syntax andsemantics.
I quite like that. Often bad style encourages bugs. In fact I wish it would go further. Like insisting on curly braces around all conditional/loop blocks even if they are only one line.
Of course if your code is so obscure and obfuscated that it takes ages to make the changes required and get rid of the warnings then clang is probably doing a very good job in getting you to straighten out the mess :)
I'm not going to be convinced until I find a clang warning that annoys me or is actually silly.
I have given you examples of both. Your tolerance for such things is obviously much higher than mine.
Well, you can turn of individual warning types with a command line switch.
Exactly what I plan to do. As would anyone who actually wants to find the errors in their program, rather than just all those things that clang deems to be not good style.
But how does forcing users to type commands that could end up hundreds of characters long actually help anyone?
There is a new Errata file for Catalina 3.12 attached to the second post in this thread. This Errata is primarily to address issues encountered when compiling Catalina under OSX using the clang compiler.
For Windows users, there is not much of interest, except for a new demo that shows how to do file name matching using wildcards in the SD Card file system (commonly called "globbing").See the file README.Errata in the attached zip file for more details.
There is a new Errata file for Catalina 3.12. This Errata is primarily to address issues encountered when compiling Catalina under OSX using the clang compiler.
For Windows users, there is not much of interest, except for a new demo that shows how to do file name matching using wildcards in the SD Card file system (commonly called "globbing").See the file README.Errata in the attached zip file for more details.
There is a new Errata file for Catalina 3.12, attached to the second post of this thread.
This Errata fixes two fairly obscure problems that only occur when using the Compact (CMM) memory model. One is that programs that used the threads library gave a compilation error when using the Spinnaker (i.e. OpenSpin) PASM compiler (they compiled with HomeSpun), and the other is that programs using the Optimizer might not execute correctly (they executed correctly if the optimizer was not used).
Comments
You said ...
There does indeed seem to be a problem building Catalina under more recent versions of OSX and XCode. My old Hackintosh was based on Snow Leopard, so I just built myself a new one based on Mountain Lion and it is picking up errors that previous versions compiled quite happily.
That part I can understand - but it is also spitting out huge numbers of very aggressive warnings for things that are in fact perfectly valid and commonplace C code, so I can't see how I can fix those - perhaps the answer is to simply disable the warnings (as you have done for gcc). I really have a bit of an issue with some of these messages - they make you think you may be doing something wrong, when in fact all you are doing is taking advantage of some perfectly valid C language features.
Anyway, I have fixed all the errors that were preventing Catalina from compiling under OSX with more recent versions of Xcode - I will post an errata file for OSX shortly.
Ross.
A far as I understand Clang can produce a lot of warnings for potentially dangerous and commonly bug prone uses of C/C++ language features even if those features are being used in a correct and useful way.
A typical example is the accidental use of "=" instead of "==" in the conditional expression of an "if". A common source of errors in C. That warning can be suppressed by using double brackets around the conditional like so: "if (( a = someFunc(x) ))". Conversely Clang will complain if you wrap the extra pair of brackets around a conditional using "==".
Here is a wonderful presentation by Chandler Carruth of the Clang team at Google explaining what Clang is up to and how it is trying to defend C/C++ programmers from Murphy's Law.
https://www.youtube.com/watch?v=NURiiQatBXA
I suspect Clang has options to turn all these warnings off individually.
Aha! That would explain why when I go "gcc --version" I get some claptrap about clang and LLVM - it would appear that even though I installed gcc I'm not actually compiling with gcc at all? How confusement!
Anyway, I have a version of Catalina that now compiles on OSX no matter which compiler you use, so I will post it shortly.
I am not interested in someone lecturing me on the many failings of C++ and how to avoid them. To me, the answer is obvious - just avoid C++
Ross.
I accept that there are some C constructs that novices routinely get wrong, and all good compilers warn you that the consequence may not be what you intended.
But some of the Xcode/clang/LLVM warnings are a bit over the top - they suggest you change your programs in ways that would make them compile, but then execute incorrectly - when there was in fact nothing wrong with the program in the first place!
Ross.
Interesting. Can you give us some examples of code that produces such warnings? I started playing with Clang a while back and haven't come across any yet.
I think you mentioned one previously. Common C usage is to assign the result of a function to a variable, then test that the variable is true before proceeding. Something like:
if (result = function(a)) { ... do something ... }This is both correct usage and so common as to be quite unremarkable. Fair enough to throw a warning about whether "==" is meant instead of "=", but the clang warning message implies that double parentheses are an appropriate solution. But this "double parenthesis" stuff is not in accordance with any C or C++ language specification that I am aware of, and in some cases could conflict badly with the "comma operator" in C. To understand this, try compiling and running the following program:
#include <stdarg.h> void print(int arg1, ...) { va_list ap; int i; va_start(ap, arg1); for (i = arg1; i >= 0; i = va_arg(ap, int)) printf("%d ", i); va_end(ap); putchar('\n'); } int main(void) { printf("case 1: "); print(0, 2, 14, 84, 97, 15, 24, 48, -1); // single parenthesis printf("case 2: "); print((0, 2, 14, 84, 97, 15, 24, 48, -1)); // double parentheses return 0; }Now, I've not thought this though in detail, but it would appear to me that suggesting "double parentheses" as a solution could in fact lead to bigger, more subtle, and much harder to find problems.
The alternative to double parentheses suggested is to replace the "=" with "==". This is certainly be wrong - it would stop the warning appearing, but will result in an erroneous program.
Basically, it is reasonable for a compiler to throw a warning, but not to suggest solutions that may be erroneous. That is a bridge too far!
All very interesting stuff, and clang/LLVM is obviously a much more sophisticated compiler than plain old gcc - but if users really require that level of sophistication to prevent them making such basic errors, it is probably a good indicator that they are programming in the wrong language.
Ross.
When I compile that example with Clang 4.7 I get warning like so:
temp.c:18:31: warning: expression result unused [-Wunused-value] printf("case 2: "); print((0, 2, 14, 84, 97, 15, 24, 48, -1)); // double parentheses ^Clearly clang is telling me that those extra braces are almost certainly not what is intended. Which seems to be quite reasonable in this case.
Am I missing a point or do you have a better example?
Odd - I don't get that warning when I compile it (nor would I expect to, since it is perfectly valid C). I don't have access to my Hackintosh at the moment so I can't check - but I think I am using clang 4.2. In any case, I think you can easily tweak the list of expressions to not be "unused" and therefore achieve the same result:
int a,b,c; printf("case 1: "); print(a=1,b=2,c=3, -1); // single parenthesis printf("case 2: "); print((a=1,b=2,c=3, -1)); // double parenthesesSo yes, I think you are missing the point. Double parenthesis can mean something in C as a consequence of various other language rules - but this meaning is not what clang suggests you use them for, which is essentially to disable a warning that I think should never really have been there in the first place (at least not as the default - fair enough if you specifically ask for such warnings to be enabled).
In any case, C already provides a mechanism for such compiler-specific behavior (#pragma). A pragma is a much clearer way of telling both the compiler and the reader that the code is in fact correct, no matter how strange it may appear. Why does clang need another mechanism, and why choose one that seems bound to confuse novice C programmers even further?
Ross.
That last example does not give me any errors or warnings in clang even with -Wall. Seems everything is working fine.
I don't see how this is going to confuse novice users. In fact the whole clang idea is to warn of typical mistakes and typeos novice make.
In that video about clang I linked to Caruth actually says they want to be as careful and conservative with warnings and suggestions. So far I have yet to find anything naff going on in what they have done.
Pragmas are ugly.
P.S. I have just realized. Clang is not worrying about brackets in your first example. The warning is about unused expression results, which is totally OK with me as it is true and redundant and almost certainly not what you meant to write. The deal with double bracketing should only come into lay when there is a possible confusion between "=" and "==".
Hi Heater,
Clang is a great compiler and I generally have no problems with it apart from the fact that it generates so many warning for perfectly valid C code, which will confuse novice programmers and encourage both novices and experienced programmers alike to turn off warnings altogether, because they actually obscure the real problems. This kind of spoils the whole point of having them!
And in some cases the warning are just plain dumb, such as the double parentheses case. Suggesting to novice users that they use double parentheses to sort out a problem they probably don't even understand does not solve the original problem at all. Instead it will just lead them to assume that the language requires you to use double parentheses, as if this construct meant something in the C language. It does not. Or rather, it does (as I have demonstrated) - but not what Clang implies that they mean!
In summary, it's a silly solution that does not address the underlying problem, and is likely to cause even more confusion in some cases.
You may not like pragmas - I don't either - but they were designed to cope with situations just like this. So why introduce another solution, and one which is non-standard, and implemented only in a single compiler?
This is my main problem with C++ - it is a language riddled with poorly conceived attempts to sort out what are in fact fairly minor problems with C. The enduring popularity of C and the continuing decline in the popularity of C++ is the result.
Ross.
if ((a = foo()) != 0) ;However, I do think clang is too aggressive about its warnings.
The specific case of "=" and "==" in conditionals and double/single brackets seems quite reasonable to me. One could force the issue by using David's method but to my eye that looks messy.
I have yet to find Clang issuing a warning that I thought was excessive or wrong. I.e. would break my code if I got rid of it. Certainly nothing to make me want to turn warnings off.
Do you guys have an example of a warning you don't like?
P.S. The Clang guys did actually remove a couple of warnings in recent Clang versions after a lot of user feedback so perhaps you are seeing more warnings than I am.
../../../propgcc/binutils/gas/symbols.c:1705:32: error: while loop has empty body [-Werror,-Wempty-body] while ((*p++ = *--q) != '\0');; ^ ../../../propgcc/binutils/gas/symbols.c:1705:32: note: put the semicolon on a separate line to silence this warningI don't like having the semi-colon on the same line as the while but it is legal syntax.
Here is another:
../../../propgcc/binutils/ld/ldmisc.c:364:46: error: adding 'bfd_boolean' (aka 'int') to a string does not append to the string [-Werror,-Wstring-plus-int] fprintf (fp, "%u%s", linenumber, ":" + done); ~~~~^~~~~~ ../../../propgcc/binutils/ld/ldmisc.c:364:46: note: use array indexing to silence this warning fprintf (fp, "%u%s", linenumber, ":" + done); ^ & [ ]Again, this is perfectly legal although kind of odd. In my case, I wasn't allowed to "fix" the code to avoid these warnings because it is part of the standard gcc distribution. Also, gcc gets built with an option that considers all warnings to be errors do I can't just ignore them either. This forced me to supply additional options to turn off the warnings in order to get propgcc to build.I think that the problem with huge numbers of warnings about things that are perfectly legal is that it tends to make people either turn off warnings entirely or miss warnings of constructs that are really wrong.
On the other hand, this more agressive version of Xcode actually found a bug in the standard gcc distribution:
../../../propgcc/gdb/bfd/bfdio.c:580:31: error: 'memset' call operates on objects of type 'struct stat' while the size is based on a different type 'struct stat *' [-Werror,-Wsizeof-pointer-memaccess] memset (statbuf, 0, sizeof (statbuf)); ~~~~~~~ ^~~~~~~ ../../../propgcc/gdb/bfd/bfdio.c:580:31: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)? memset (statbuf, 0, sizeof (statbuf)); It looks to me as though this should really be: memset (statbuf, 0, sizeof (*statbuf));This is for the following code and I believe it is really a bug in gcc:static int memory_bstat (bfd *abfd, struct stat *statbuf) { struct bfd_in_memory *bim = (struct bfd_in_memory *) abfd->iostream; memset (statbuf, 0, sizeof (statbuf)); statbuf->st_size = bim->size; return 0; }I'm going to side with clang on the "while loop has empty" body warning. In your example you have two semi-colons following the while which is just dumb. Remove one of them and there is no more warning. (Mind you I now wonder why it says "loop has empty body" when a single semi-colon there is still a loop with an empty body)
I'm also going to side with clang on the adding integer to a string thing. That's just a nuts thing to do. Especially since if I add a line like that to a test program I have here it segfaults:
unsigned linenumber = 0; int done = 0; printf ("%u%s", linenumber, ":" + done);What on Earth is GCC trying to do here?That "sizeof" thing is a classic. It's one that Chandler Caruth talks about in that clang presentation video. Seems clang has found thousands of those errors in all kinds of famous projects where they have been lurking for years. I agree. And that is why clang has removed a couple of over enthusiastic warnings by default. I am not seeing lots of annoying warnings.
If GCC is written in a sloppy way that is hardly clang's fault.
There is a delicious irony in the way the excessive warnings that clang emits over GCC are being argued against here whilst at the same time we see bugs being discovered in GCC by clangs warnings!
So, any better examples of "wrong" warnings?
Seems that what clang's warning is suggesting is that it is written as: Which is even more sick. It looks horrible and conceptually we are indexing and array with what is intended to be a boolean. Gak!
But I would keep the warning as it is pointing out that you have written a really horrible piece of code.
P.S. The segfault was actually a myfault
It has been said that the arrival of clang caused a spurt of rapid developments and improvements in GCC. Something about having to compete with the new kid on the block.
Perhaps clangs warnings will also spur he GCC guys to clean up their code !
I'm with David on this one. I have a large amount of perfectly legal C code which spits out a huge number of silly warnings when compiled under clang. It also spits out a few legitimate errors that gcc didn't catch, so that's a good thing - but these were completely obvious and trivial errors that took about 2 minutes to fix, whereas I have now spent many hours trying to address all the other warnings, and still have many left to go. Each one requires me to verify that the code is legal (which it is) and is working correctly (which it is). Even so, under clang I have no alternative but to change the code to prevent the warning - and of course every time I change the code I have to test it to make sure I have not made a silly typo and accidentally introduced a bug!
This has taken so much time that I have now decided to abandon thew whole effort and instead disable the warning altogether. So the whole thing has been completely counterproductive, The clang compiler seems to think it's job is to police programming style in addition to syntax and semantics. It's infuriating!
Ross.
I'm not going to be convinced until I find a clang warning that annoys me or is actually silly. I have to ask again, do you have an example of such warnings?
Of course those warnings are in perfectly legal C code, that is why they are warnings and not errors. Well, you can turn of individual warning types with a command line switch. For example: I quite like that. Often bad style encourages bugs. In fact I wish it would go further. Like insisting on curly braces around all conditional/loop blocks even if they are only one line.
Of course if your code is so obscure and obfuscated that it takes ages to make the changes required and get rid of the warnings then clang is probably doing a very good job in getting you to straighten out the mess
Exactly what I plan to do. As would anyone who actually wants to find the errors in their program, rather than just all those things that clang deems to be not good style.
But how does forcing users to type commands that could end up hundreds of characters long actually help anyone?
Ross.
There is a new Errata file for Catalina 3.12 attached to the second post in this thread. This Errata is primarily to address issues encountered when compiling Catalina under OSX using the clang compiler.
For Windows users, there is not much of interest, except for a new demo that shows how to do file name matching using wildcards in the SD Card file system (commonly called "globbing").See the file README.Errata in the attached zip file for more details.
Ross.
There is a new Errata file for Catalina 3.12, attached to the second post of this thread.
This Errata fixes two fairly obscure problems that only occur when using the Compact (CMM) memory model. One is that programs that used the threads library gave a compilation error when using the Spinnaker (i.e. OpenSpin) PASM compiler (they compiled with HomeSpun), and the other is that programs using the Optimizer might not execute correctly (they executed correctly if the optimizer was not used).
Ross.
Ross.