undefined variables

[RobertVanA]

During reading a bitmap file an error occures. The statement

hq = color_table(k)

produces the error message:

"The variable (color_table(221)) has an undefined value."

followed by a traceback.

Color_table is an allocated array. The elements of this array and the scalar hq
are both of type RGBQUAD. Such a structure has 4 members, each being a 8-bit integer.

I have tried to remove the check: chk(u) but that did not changed anything.
I have tried to check whether a component has the "-117" value
(indicating "undefined") but that did not help.
Allocatable versus fixed length does, again, make no difference.
Reading simple integers in stead of the RGBQUAD structures show
the same error.

For your information: the error occured while reading a 8 bit .bmp file.
The 24 bit bmp files works fine.
Each component of the RGBQUAD structure is a 8 bit integer and
indicates an intensity of color. Therefore, any value
(between z'00' and z'FF') is allowed, so any bitpattern
is perfectly valid. "Undefined" can not be associated with any
form of problem-error.
When I skip the elements of the array that gives problem,
(by setting those RGBQUAD elements that causes the probleme to a determined value)
the final bitmap produces a well behaved picture on screen.

What 's going wrong here? How can I handle this type of hick-up?

Thanks!

Robert van Amerongen

[mecej4]

From the descriptions of the symptoms given by you, one cannot infer that there is anything wrong at all.

When the special pattern used for detecting uninitialized variables is a legitimate value from the point of view of one's application, one should either not use the -chk(u) option, or should ask the runtime to ignore the false reporting of 'undefined'.

I have tried to remove the check: chk(u) but that did not changed anything -- what do you mean? Did you continue to get '..has an undefined value' error messages with -chk(u) turned off?

If you can put together a small example and post the relevant code and data, someone may be willing to take a look.

[RobertVanA]

Thank you for the response. Indeed, if I do discard the chk(u) test, the message "undefined" still occurs. That does surprise me! I will enclose a file with a typical failure case. May be it helps you to clarify.
Thanks for your kind help,
Robert van Amerongen

[mecej4]

I uncommented the three lines (167-169) of myLoad_BMP.f95, and compiled as follows:

lf95 -mod c:\lang\lfpro\win32\lib -ml msvc Test_BMP.f95 my_LoadBMP.f95 glu32.lib glut32.lib user32.lib

and obtained the results

S:\lahey\bmp_test>test_bmp
Call to my_LoadBMP with the file: crate.bmp
...(as in your all_went_oke.doc)
call returned met ierror: 0
test_bmp ended where it ought to end!!

Commenting out the same three lines as above, recompiling and rerunning the program gave the same output on StdOut.

With checking for undefined variables turned on, the program crashed with index8 on line 194 'undefined'. However, the special byte value used to signify undefined, -117, happens to be in your bit-map. Therefore, checking for undefined values in the usual way is not possible, and should not be attempted.

Perhaps, you need to erase all .OBJ files and do a clean build from scratch?

[RobertVanA]

You did a great job. When I follow your guidline as far as the command line concerns, everything is oké. There is no difference between using -ml winapi or -ml msvc as you used. Linking the three files is not necessary. When using -chk(u) the program fails, as we can expect. Thus, so far so good.

My program, however, was not builded from the command line but with Visual Studio. As you showed me that the program itselves is correct, the problem must be in the settings. After some time, I realised that there is a difference between the PROJECT settings and the FILE settings. Although the project did not use the -chk(u), the file "my_loadbmp.f95 did, so ,,,

Once this was removed everything went fine.

I very appreciate your help, it was very, very helpful for me!

Thanks,
Robert van Amerongen.