I have a function that should return the SysTick variable:
uint32_t TickGet(void){
return SysTick;
}
However SysTick is defined as an int:
int SysTick;
For some reason, the XC32 compiler is perfectly happy with this arrangement. No warnings warnings whatsoever are thrown. Not even with -Wall as a XC32-GCC option.
Does anyone know how to get the XC32 compiler to list this warning?
edit, ofcourse I want the SysTick variable to be defined as an uint32_t. That's besides the point, my problem is with the compiler not throwing warnings for such occasions.
Related
#include <iostream>
int func(int &a,int &b){
if (a>b){
return 1;
}
}
int main(){
int a=4,b=12;
std::cout<<func(a,b)<<std::endl;
}
I think a run time error should occur because a is smaller than b, and the return statement is skipped. But it actually outputs the value of b no matter how I change the value of b. Could you please tell me why?
it should detect a run time error
That is not the case. The behaviour is undefined.
It seems to be related the value of b, why is that happening?
Because the behaviour is undefined.
This is happening because a result of functions (if the return type is int) is transferred using rax register of CPU. return keyword places its argument in this register and returns to the caller function. But there is also an implicit return keyword at end of any function in C/C++ (if there is no explicit return placed by a programmer). And this is why this function returns control flow to the caller function.
But contents of rax register should be treated in this case as random because the compiler can use it for any variable or even totally ignore it.
Falling out of a non-void function without returning is undefined behaviour, there's nothing your program or the runtime "should" do in that case.
You should not suppress the compiler warnings!
gcc says:
main.cpp:35:1: warning: control reaches end of non-void function [-Wreturn-type].
As others already mentioned: Your program has UB! So read the warnings and fix your program accordingly!
it should detect a run time error
And there is no need for run-time error, as the error is visible during compile-time! The core language has no run-time errors at all. If you see some error messages during program execution, it is coming from library code like a called "terminate" from an exception or something else.
It is good to have all the warnings enabled and also sometimes helpful to run different compilers over the code to get most of warnings possible.
For gcc you could add:
-Wall -pedantic -Wextra
That enables a lot of warnings, but not all. There are still some warnings which are not addressed like: -Wsuggest-override
In C++ if a function is declared to return a value but it doesn't, it is undefined behavior
I have the following code sample:
void some_function()
{
int ret = do_something();
if(ret == SOME_ERROR)
return;
}
Afaik the last if is useless as the function returns no matter what value ret has. I'd expect a warning or at least an info by the compiler (I use GCC 6). I also tried to enable all warnings from this thread but still nothing. Is there any difference between returning with a return statement and returning at the end of a void function or does it get optimized anyways (but I still think a warning would be useful then)?
Compiler warnings should maintain the balance between false positives and false negatives.
Too many warnings - and you'll spend a lot of your time walking through them without any actual improvement (or, more realistically, you will disable them altogether).
It is hard enough to imagine a situation where such a warning shows a real problem with the code, and not just a minor stylistic issue.
Consider, for example, -Wunused. It is pretty often indicates that you misspelled some variable name, or forgot this:
float x = ...;
float y = ...;
return atan2(y, y);
//x is never used, probably an error
Your example could be a diagnostic for a static analysis tool, but too minor to be useful as a general compiler warning.
A void function can perfectly return.
That's why you don't see no error/warning. From my answer, even I use some useful flags, I will get nothing:
Georgioss-MacBook-Pro:~ gsamaras$ g++ -pedantic -Wall -Wextra -Wconversion main.cpp
Georgioss-MacBook-Pro:~ gsamaras$
You want to do this when you want to terminate the function, but you do not need to return anything at all.
Try to do return 5; and you will get an error, of course.
You have written fully legitimate code.
So there is no error from the compiler.
!If! you enable optimizing it will be optimized away.
You can see it here:
https://godbolt.org/g/pUr7eP
Maybe this will be flagged by some static analyzer.
hi i have a question.
bool testFunction(int arg) { int value = arg; }
this function is not error on gcc & vs. only warning occur.
but in xcode, this source is error.
"control reaches end of non-void function"
i dont know why error occur in xcode.
sure Treat Warnings as Errors option set NO in xcode.
thank you.
In C++, returning nothing from a non-void function is Undefined Behavior.
Remember that compilers are not supposed to eliminate UB from your code. They simply cannot detect all UB patterns; they can only warn about it when they "suspect it".
The fact that this pattern is left "allowed" is for backward compatibility with old code. It is the responsibility of the programmer.
In most, if not all compilers, there is an option to set this specific warning as an error. This option is other than the "Treat all Warnings as Errors". It seems to be set in your XCode environment. Look at this thread for how to find this option in XCode.
Different compilers warn about different things.
An error or warning should really occur in this case because your function should return a value.
If you add the -Wall or -Wreturn-type flag to g++ you will get a warning.
You can do the equivalent in Xcode by adjusting the build setting 'Mismatched Return Type' value. There are three settings.
Yes - warning
No - ignore
Yes (error) - treat this as an error
See attached screenshot.
Turning this off might lead to you missing other errors so it would be best to leave it at the Warn setting at least.
I'm getting this warning on a stack variable:
warning: object.member may be used uninitialized in this function
In this case I do not wish to force initialization to just to get rid of the warning as it consumes CPU cycles. The variable is a POD structure so a memset on it is not zero cost. I can verify that the variable is never used uninitialized, so I'd just like to suppress the warning for it.
In general I do want the warning, just not on this particular variable in this particular scenario. How can I suppress the warning?
Looks like the pragma diagnostics are the correct way to go but they require quite a recent version of GCC (4.6)
No acceptable solution prior that version is known.
Try doing this:
#pragma GCC diagnostic ignored "-Wuninitialized"
foo(b); /* no diagnostic for this one */
This pragma comes in three interesting and helpful flavors : warning, error, ignored. See 6.56.10 Diagnostic Pragmas for their usages. The link says,
GCC allows the user to selectively
enable or disable certain types of
diagnostics, and change the kind of
the diagnostic. For example, a
project's policy might require that
all sources compile with -Werror but
certain files might have exceptions
allowing specific types of warnings.
Or, a project might selectively enable
diagnostics and treat them as errors
depending on which preprocessor macros
are defined.
The accepted answer has two big problems that requires more than a comment.
First, it deactivates the warning for the whole file. If that pragma resides in a header, probably for more. Warnings are useful and if it is indeed a false positive, one should disable the warning for a bunch of code as small as possible.
Then the warning in the OP is "maybe uninitialized" which is deactivated by -Wmaybe-uninitialized, as opposed to -Wuninitialized.
#pragma GCC diagnostic push // save the actual diag context
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized" // disable maybe warnings
function() or int variable; // impacted section of code
#pragma GCC diagnostic pop // restore previous diag context
GCC differentiates between uninitalised and self initalized, e.g. compiling:
int main() {
int i = i;
return i;
}
With gcc -Wall -Wextra gives no warnings, unless you explicitly added -Winit-self as well, yet it gets completely optimized out by my quick testing.
#Nawaz has answered the question as specifically asked, but have you considered that the fact that you need this may indicate you're declaring your struct too early/at a less nested scope than appropriate? It would generally be much preferred if you could declare your struct at a point where you can actually initialize it rather than declaring it earlier and filling it in various locations.
Also, even though you can verify that it's never used uninitialized right now, what if someone else adds a new code path in the future and it's not initialized properly? If you disable the warning then it'll silently compile and probably break in an unexpected way. Unless you can prove that the initialization is taking a measurable amount of your program's CPU it's probably better to just do the initialization up front.
Selectively disable GCC warnings for only part of a translation unit?
Can someone explain to me why the following code compiles? Is it ignored by the compiler?
#include <stdio.h>
int main() {
1234;
return 0;
}
The Standard obliges implementers to allow statements even with no apparent effect. This is mainly because through the magic of macros and templates, they're surprisingly easy to come up with.
There is nothing wrong with this code. It's completely legal. It doesn't do anything, but it's completely legal. Your compiler -- with the right warning settings -- may warn you that it's utterly useless, but it's completely compliant.
A good compiler will give you a warning that you have a statement that has no side effect a (null statement effectively), however null statements are allowed in C/C++ so there will be no compile error.
You can think of the statement 1234; as similar to the statement getc(); in that both statements "return" (evaluate to) a value, but nothing is done with the return value. The getc() call has the side effect of consuming a character from standard input, so you're more likely to see that in a program than a bare number. But both are legal.
DeadMG has a good note on why it's a good idea to allow this. It's not because 1234 might be defined as a macro (because as far as I know, that's not allowed). It's because, especially with more complex macros, it's easy to end up with a macro that might reduce to some statement that doesn't do anything.
In C (and thus C++), an expression is a statement and is evaluated for its side effects even if the result is discarded. If it doesn't have any side effects, the compiler might find out and optimized it away (very likely in your case), but it must still compile the code.
Of course, any compiler will warn about that if that warning isn't disabled explicitly.
Turn on warnings.
Set warnings to be treated like errors (as they usually are).
Now it will behave as you would expect:
> cat t.cpp
int main() {
1234;
return 0;
}
> g++ t.cpp -Wall -Wextra -pedantic -Werror
cc1plus: warnings being treated as errors
t.cpp: In function ‘int main()’:
t.cpp:2: warning: statement has no effect
Its just that default compiler settings are lax
Because 1234 is a constant, it lets you get away with it. Replacing it with 'x' (without declaring variable x) or 'This doesn't compile' should cause it to fail.
Essentially it is an empty statement, so no harm no foul and it discards the code and keeps going.