Detecting uninitialized arrays or going past bounds

[van_der_merwe__ben]

We compile a number of Fortran files using the /Qzero option. Does it only initialize local variables of scalar and instrinsic type, but not dynamically allocated arrays? Is there something to intialize arrays as well?

I notice that version 12 of the compiler now issues a runtime error if you declare a character array and then pass it to another routine which reclares to be larger than it actually is. Great! Likely we are getting this because we mix C++/C+Fortran and use the flag to pass the string size around to subroutines as well. Is there perhaps a way to turn on a similar test for real arrays? The range checking does catch real array bound violations, but if you redeclare the array to be larger than it is, I do not think it catches that (other than for character arrays).

The compiler has an option, /CU or /check:uninit I think, which can trap unintialized memory. Does it only trap simple local variables or also arrays or parts of arrays? What does it not check?

We compile something like 6000 (I kid you not) Fortran files along with C and C++ code, and any tool or option or ideas I can use to help diagnose memory corruption or uninitialized memory is always very welcome. For our C++ code we use pageheap and Purify, but Purify can not handle any DLL that contains even one Fortran object file.

[Andrew_Smith]

I find initializing as much as possible to nan is a better way to detect use of unitialised memory. Initialising to zero means you never find them! If you are not certain that zero is the correct initial value you always wonder if the results are all wrong!

Please Intel can we have /QNaN and is there something similar we could do for other than floating points types.

[mecej4]

I agree that zeroing uninitialized memory is bad policy. It is similar to sweeping dirt under the carpet.

"is there something similar we could do for other than floating points types"

Unlike floating point, for which there is an IEEE standard specifying NaNs and rules for handling NaNs, for other data types there is no bit pattern for a byte, half-word, long word, etc., which does not map to an invalid value. Compilers that check for uninitialized variables of these types have to use some pattern that is less likely to be used in a user's application. That is why compilers that have facilities for checking uninitialized variables often let the user select the initialization value.

When processing a bit-mapped image, for example, there is no invalid bit pattern that one can rely upon. Using any bit pattern for "undefined/uninitialized" can lead to frustrating false positives.

[van_der_merwe__ben]

So you are all telling me the only way to fix noise (changes in results) is to hunt down where you have some real array or something that is not being initialized? And there is no compiler option or flag to aid with that?

[Steven_L_Intel1]

There are a couple of options that would help. /check:uninitialized is one, though it will tend to catch local variables only. I also recommend /warn:interface and /check:bounds. In version 12 the new "Static Security Analysis" feature, in conjunction with Intel Inspector XE, can detect more errors of this type.

[van_der_merwe__ben]

Thank you Lionel, we are using /check:uninitlized and /check:bounds already, but not (yet) /warn:interface and -diag-enable sc3 (assuming one can use it all the time rather than a one time pass).

[Steven_L_Intel1]

-diag-enable:sc3 is something you want to use in a separate build configuration as it prevents creation of an executable.