struct Thing {
std::string something;
};
Clang-tidy complains:
warning: an exception may be thrown in function 'Thing' which should not throw exceptions [bugprone-exception-escape]
I know about the bugprone-exception-escape.FunctionsThatShouldNotThrow setting, but I could not figure out what to put there to suppress that warning for all structures that contain strings.
Any suggestions?
It is a bug in the check, see https://github.com/llvm/llvm-project/issues/54668, apparently introduced with LLVM 14. Going by the issue description there isn't really much you can do except suppressing it individually for each class.
If that is too much work, you might want to consider disabling the check until they have fixed this. According to the linked issue a fix is already under review: https://reviews.llvm.org/D134588
Related
#include <vector>
std::vector<int>::iterator foo();
void bar(void*) {}
int main()
{
void* p;
while (foo() != foo() && (p = 0, true))
{
bar(p);
}
return 0;
}
Results in error:
c:\users\jessepepper\source\repos\testcode\consoleapplication1\consoleapplication1.cpp(15): error C4703: potentially uninitialized local pointer variable 'p' used
It's kind of a bug, but very typical for the kind of code you write.
First, this isn't an error, it's a warning. C4703 is a level 4 warning (meaning that it isn't even enabled by default). So in order to get it reported as an error (and thus interrupt compilation), compiler arguments or pragmas were passed to enable this warning and turn it into an error (/W4 and /Werror are the most likely I think).
Then there's a trade-off in the compiler. How complex should the data flow analysis be to determine whether a variable is actually uninitialized? Should it be interprocedural? The more complex it is, the slower the compiler gets (and because of the halting problem, the issue may be undecidable anyway). The simpler it is, the more false positives you get because the condition that guarantees initialization is too complex for the compiler to understand.
In this case, I suspect that the compiler's analysis works as follows: the assignment to p is behind a conditional (it only happens if foo() != foo()). The usage of p is also behind a conditional (it only happens if that complex and-expression is true). The compiler cannot establish a relationship between these conditions (the analysis is not complex enough to realize that foo() != foo() is a precondition to the entire while loop condition being true). Thus, the compiler errs on the side of assuming that the access could happen without prior initialization and emits the warning.
So it's an engineering trade-off. You could report the bug, but if you do, I suggest you supply a more compelling real-world example of idiomatic code to argue in favor of making the analysis more complex. Are you sure you can't restructure your original code to make it more approachable to the compiler, and more readable for humans at the same time?
I did some experimenting with VC++2017 Preview.
It's definitely a bug bug. It makes it impossible to compile and link code that might be correct, albetit smelly.
A warning would be acceptable. (See #SebastianRedl answer.) But in the latest and greatest VC++2017, it is being treated as an error, not warning, even with warnings turned off, and "Treat warnings as errors" set to No. Something odd is happening. The "error" is being thrown late - after it says, "Generating code". I would guess, and it's only a guess, that the "Generating code" pass is doing global analysis to determine if un-initialized access is possible, and it's getting it wrong. Even then, you should be able to disable the error, IMO.
I do not know if this is new behavior. Reading Sebastian's answer, I presume it is. When I get any kind of warning at any level, I always fix it in the code, so I would not know.
Jesse, click on the triangular flag near the top right of Visual Studio, and report it.
For sure it's a bug. I tried to remove it in all possible ways, including #pragma. The real thing is that this is reported as an error, not as a warning as Microsoft say. This is a big mistake from Microsoft. It's NOT a WARNING, it's an ERROR. Please, do not repeat again that it's a warning, because it's NOT.
What I'm doing is trying to compile some third party library whose sources I do not want to fix in any way, and should compile in normal cases, but it DOESN'T compile in VS2017 because the infamous "error C4703: potentially uninitialized local pointer variable *** used".
Someone found a solution for that?
I don't know if what I'd like is possible, but I figure give it an ask anyway.
I have some Boost library code where I'd like to hint to clang-tidy to issue a warning where through static analysis, a clear instance of undefined behaviour could occur due to bad logic. https://akrzemi1.wordpress.com/2016/12/12/concealing-bugs/ suggests that __builtin_unreachable() might get clang-tidy to trip like this, but I have failed to make it happen (though it trips the UB sanitiser very nicely):
#include <optional>
int main()
{
std::optional<int> f;
// Spot the UB before it happens and flag it
if(!f)
{
__builtin_unreachable();
}
// Here is the UB
return *f;
}
In the code above, a static analyser can clearly tell that __builtin_unreachable() must be called. I want clang-tidy to report this, yet clang-tidy-5.0 -checks=* -header-filter=.* temp.cpp -- -std=c++17 reports nothing.
Note I don't need to use __builtin_unreachable(), it's just what Andrzej's C++ Blog suggested. Any technique for getting the clang static analyser, or the MSVC static analyser, or ideally clang-tidy, to deduce when UB must obviously occur through static deduction and flag it at compile time is what I am looking for.
What I am not looking for is a construct which always trips a warning during static analysis irrespective of use case. I only want the static analysis warning to appear when through static analysis alone, it is obvious at compile time that UB could be invoked given some statically deducible logic error.
My thanks in advance!
So, yeah, it turns out that this cannot be done in clang-tidy at least, and probably most other static analysers.
The gory details of why not can be found at https://lists.llvm.org/pipermail/cfe-dev/2017-June/054120.html, but in essence:
The halting problem i.e. no idea if and how loops are executed.
clang-tidy and other analysers are built to avoid seeing dead code as much as possible. This exactly is opposite to what is needed for the kind of check above.
I'm working on a school project that involves porting a large piece of C++ code on an experimental piece of hardware. Unfortunately, that hardware is 64-bit and the code contains many instances of pointer arithmetic that expects pointers to be 32-bit, i.e. it often does reinterpret_cast<uint32_t>(ptr).
Going through them one by one would be very tedious and since this is an experimental project anyway, I'm happy to settle for a "hackish" workaround. So instead I modified the implementation of malloc to ensure it never allocates memory above the 4GB limit. Technically, these casts should therefore be valid.
Question is, how do I explain this to Clang? The error I'm getting is: error: cast from pointer to smaller type 'uint32_t' (aka 'unsigned int') loses information. Is there a way to disable it?
Thanks,
David
I was able to disable this with -fms-extensions after getting this from someone on the Cpplang Slack:
Looking at "DiagnosticSemaKinds.td" it shows up as err_bad_reinterpret_cast_small_int, https://github.com/llvm-mirror/clang/blob/release_50/include/clang/Basic/DiagnosticSemaKinds.td#L6193
There are two occurences in "SemaCast.cpp" -- one of which suggests it's sensitive to MS extensions, https://github.com/llvm-mirror/clang/blob/release_50/lib/Sema/SemaCast.cpp#L2112
One could try -fms-extensions (hopefully not -fms-compatibility), but that would bring all the shebang with it.
I agree that you should bite the bullet and fix the code to use the correct integer type. But to answer your question: No, you can't disable it, though you can work around it.
Many errors come from warnings. A good thing in general, but if you want to disable the warning, just do it. Since the culprit is probably something like -Wall which enables many warnings you should keep on, you should selectively disable this single warning. The error message mentions the diagnostic responsible for error message, e.g. ... [-Wextra-tokens] (if it doesn't, remove the -fno-diagnostics-show-option flag). You can then disable this diagnostic completely by adding -Wno-extra-tokens (again, the "extra tokens" warning is an example), or turn it into a non-fatal warning by means of -Wno-error=extra-tokens.
However, this specific error is not due to a warning and I can't find any option to disable errors (makes sense, since most errors are fatal).
But to just truncate the integer value and not having to fix all the wrong uses of uint32_t just yet, you could use static_cast<uint32_t>(reinterpret_cast<uintptr_t>(ptr)). Needless to say, this will still be wrong.
how about using uintptr_t, most of your pointer arithmetic may still works.
Save this piece of code as mycast.hpp and add -include mycast.hpp to your Makefile.
#include <cstdint>
template<typename U, typename T>
U Reinterpret_cast(T *x) {
return (U)(uintptr_t)x;
}
template<typename U, typename T>
U Reinterpret_cast(T &x) {
return *(U*)&x;
}
#define reinterpret_cast Reinterpret_cast
They should do their job unless your code is too tricky.
Your strategy will not work for stack-allocated objects, be careful!! You can insert some debugging/logging logic to Reinterpret_cast if necessary.
I hit this same problem in a project without C++11, and worked around it like this:
inline int PtrToInt(void* ptr)
{
void* clang[1];
clang[0] = ptr;
return *(int*)clang;
}
I'm working on a proprietary unix-like os (I don't know if that's relevant though) and compiling with g++.
I noticed recently that if I put xml-like tags in my C++ comments I get compiler errors. I don't particularly need to do this, but I thought it was strange and I'd like to know why it's an issue for the compiler. For example:
// <debugoutput>
std::cerr << "I'm debugging!" << std::endl;
// </debugoutput>
would cause massive compiler errors if it were in the middle of my code somewhere. Changing the last comment line </debugoutput> to <debugoutput> makes it compile fine though.
Does anyone know why the compiler would be confused by that line being in a comment? The compiler errors generated when this happens don't seem related at all - they're more like what you'd see if you missed the semi colon on the end of a class, undefined references to well defined classes, etc. I can't paste the output from my dev system, but trust me that it doesn't look related to the issue - its more like the compiler got confused.
This sounds suspiciously like a digraph related issue, but without the actual error message or a small code sample that exhibits the problem it's hard to tell for sure.
Try changing the whitespacing between the <, / and actual text, as well as try it within a C-style comment to see if that provides additional insight.
For information on C/C++ digraphs and trigraphs see http://en.wikipedia.org/wiki/C_trigraph#C and also Purpose of Trigraph sequences in C++? and Why are there digraphs in C and C++? from SO.
It seems possible that there is some sequence being picked up (for example </ as a digraph and it's throwing off the compiler).
Is there a way, in VC++ (VSTS 2008), to froce a compiler error for functions that do not explicitly return a value on the default return path (Or any other quick way to locate them)?
On the same issue, is there any gaurentee as to what such functions actually return?
I don't know exactly the warning number, but you can use #pragma warning for enforcing a specific warning to be treated as error:
Example:
#pragma warning( error: 4001)
will treat warning 4001 as error
If you enable max warning level, and treat warnings as errors, you'll surely find what you're looking for. A guess as to what will be returned otherwise: A default-constructed object of the function's return type.
VC will warn about many instances of this problem, but fails to detect some. I've repeatedly caught it missing this problem in function templates, but I've seen int in some plain functions, too. Treating warnings as errors (compiler switch for all warnings or pragma for specifc ones) will make it impossible to overlook those it finds.
For those VC overlooks you have to use more thorough tools. AFAIK in VSTS you can also throw an /analyze switch for the compiler and have it find even more problems.
There's also many versions of lint-like programs.
Using some other compiler helps, too. Porting a VS project to GCC for the first time can be quite hard, but I think Intel's compiler can be used as a drop-in replacement for VC and compile VC projects right away. Comeau C++, too, has switches for being quite VC-compatible and has incredibly good errors messages.