Local Variable Initialization (variable possibly uninitialized, but it is initialized?)

[emoser]

I am having very bizzare behavior with my code. Some error messages complaining about referencing uninitialized variables led me to search around and I discovered that the shareware I am using has very little initialization of local variables. CVI gives compiler warnings about these variables, and I do not think it caught even close to all of them. So I went through the entire file and initialized everything myself.

Even after I initialize my variables though, the compiler still says they are unitialized, and my code still fails. I have attached a screen of the compiler warnings along with one of the problem functions. Notice that in the first warning ( 36, 9 warning: variable '(*tw1).i' is possibly uninitialized when used here ) it has two notes under it, one that tells me where the variable is declared and one that says "1, 1 note: add initialization to silence this warning". When I double-click on this note it points to the top of the file, as if it is telling me to initialize the variable outside of the function.

I also found a very simlar post on this but the user said they were defining the same structure twice.

http://forums.ni.com/t5/LabWindows-CVI/Local-array-initializations-not-recognized/m-p/2638119/highli...

Also, I understand that in the screenshot I have not yet initialized the members of my structure, which I plan on doing once I get rid of these warnings.

What must I do to remove this error? Any help is greatly appreciated, I've been messing around with this for too long. Thank You!

[Johannes_T]

Hello emoser!

I was unable to reproduce the symptom by reconstructing the code based on your screenshot, so I would need more information about your setup:

1. The exact version of LabWindows/CVI that you are using: e.g. CVI 2013, CVI 2013 SP1, CVI 2013 SP1, etc.
2. Some minimal project with source code that reproduces the issue. The project will also contain useful indication about the Build Settings you have enabled (e.g. Debugging Options settings).

Thank you!

- Johannes

[Johannes_T · Accepted solution]

emoser,

I think the strange warning is due to some uninitialized variables analysis bug in the compiler. The incorrect diagnostic is issued at the line where you define a local pointer variable to structure kiss_fft_cpx. It seems that the warning is caused when the pointer variable declaration is followed immediately by a local declaration of a structure of the same type:

kiss_fft_cpx *tw1 = NULL;

kiss_fft_cpx t;

Basically the incorrect diagnostic will happen:

1. if a local pointer variable to a struct typedef is followed by a variable declaration of the same type.
2. if the second local variable declaration is not initialized.
3. regardless whether the pointer variable is initialized or not.

The bug might be caused because the compiler might assume that the memory region in the data segment continues from the pointer variable through the definition of the second variable, because they are of the same base type. A possible workaround in your case would be to move the variable declaration of the same type (in your case the declaration of variable t) before the declaration of the pointer:

kiss_fft_cpx t;

kiss_fft_cpx *tw1 = NULL;

Fortunately this issue is fixed in the latest LabWindows/CVI 2015 release.

I hope this helps. Let me know if the workaround works for you.

Best regards!

- Johannes

[emoser]

I appreciate the response. I am using LabWindows/CVI 2013, according to the licence manager (no SP1 or anything). 

I changed the order of the declaration so that the local variable is declared above the pointer and all warnings were eliminated.

This rules out the possibility that CVI was causing my code to fail. The code I am using is very lengthy and complex, and involves recursive calls. In fact, I am not sure how the code works, I am only trying to get it working since it is a publicly available library (the KISS FFT library). I was thinking that the fact that the variables were uninitialized was causing the issues. However, it seems that the code itself contains errors.

We have decided to move foward and abandon this code. I apprecieate the help.