variable is used before its value is set

Hi Alexander,

I think that the simplest solution is to assign them values in declaration. Something like:

float f32P=0, f32Pb=0, f32Param=0;

Although it is not needed, I think it is better to always initialize variables.

doing such init as proposed is impacting badly on performance. you understand, i dont want to add such codes.

its further globbering code with statements that are not needed and thus is also damaging code maintainablity.

furthermore there are international coding standards where you have to explain anything you do in codes. just imaging someone would ever ask me why i am initializing that value to e.g. "0" and not "3.145"...

the main thing is that a sequence like this:

int a, b;
a = b;

does raise warning #551-D with total justification. but the other case does raise the very same warning with only a speculative reasoning. the problem is that its the very same warning number - thus i can not kill the one case whilst keeping the other justified one. i really even dont know which switch enabled that set of speculative warnings as they were not popping up when only using default settings

so i hoped for someone that is understanding the issue a bit better than me. maybe it was not explained clear enough in the initialy where my problem really lives.

Ok. Now I see your point.

I have taken a look at this document: http://www.ti.com/lit/ug/spru187u/spru187u.pdf

I am not familiar with MISRA and ARM but I think you should read section 6.9 (if you have not) which talks about pragma directives. In particular, CHECK_MISRA and DIAG_XXX pragmas. I am not sure but they may help you. In any case, if you can disable the warning with them, you may have to re-enable it after the call since, as you said, sometimes it is justified.

if it were a MISRA warning then it would look like that one:

"<some-path>\c6000_7_4_2\include\string.h", line 124: warning #1410-D:
(MISRA-C:2004 13.1/R) Assignment operators shall not be used in expressions that yield a Boolean value

The keyword for disabling it would include such a sequence "-13.1". There is no such part for 551-D.

Hi,

As it was said, you could use a #pragma diag_supress 551 where your initFloat function is defined, I think that this would disable all 551-D warnings in that file. But I'm not sure if this is what you want and it wouldn't solve the problem. I suggest that you post your question in the compiler forum, because the warning that you're getting maybe a compiler's bug.

But before you close the thread, can you explain me what you mean by?

Alexander Stohr said:

doing such init as proposed is impacting badly on performance.

I didn't understand why zero initializing the variables will have a negative impact on performance.

Thanks

J

i am having the message on numerouse places.

globbering all my codes with such statements in enable-disable clamping is sort of a mess for my impression as it bloats the code. valid code should not need such extra statements. disabling a check for a whole file would disable the check for all places even for the legitimate ones.

on the supposed effect of init on perfomance:

it was a rough first impression that any setting of a memory location needs time for the core that executes it and its a bus load. it further might affect caches. on certain compilers this can be hidden in e.g. in the overhead of calling some function later on but thats not sure at all. in cases where the function is declared inline the compiler might sometimes even be in state of removing all such access, but thats not sure at all. - thus the initial assumption that some init will use up some resources and thus will impact on performance is still justified.

Edit: ah, i was providing "InitF32()" in the sample. in the codes where i get the warning its a much more complex operation than just initisaliation. you might better understand if it were "SetToMuchComplexComputationResult(a,b,c,d,e,&f)" where f is the critical item.