forums.silverfrost.com

[MarzAttax]

Hi there,

I have a routine that accesses binary-data in an array.
I have Full checking code ticked.

One of my routines crashes with:

Error 112, Reference to undefined variable, array element or function result (/UNDEF)

Indeed my array does have UNDEFINED in them.
However, I was told a while back to use "cFTN95$INHIBIT_CHECK 11" in order to "turn off" UNDEF for a file. Since I am using the ".f95" extension for my code I attempted to use "!FTN95$INHIBIT_CHECK 11" (as the first line of my source-file) but this appears not to work since I get the error as show above.

Please advise.

Marz

[PaulLaidler]

You can disable checking options via a comment embedded directive but number 11 does not relate to /UNDEF.

Try

!FTN95$OPTIONS(-UNDEF)

and look at a /LIST or /EXPLIST to see if it has worked.

Better still, do not use /UNDEF on the command line (use /CHECK rather than /CHECKMATE).

Even better, are you sure that you need to switch this off. What will happen at runtime if values are not set?

[MarzAttax]

I do not recall the exact wording that was used when I was told to use "cFTN95$INHIBIT_CHECK 11", but in the ".for" file it "appeared" to have worked.

I have no idea what /LIST and /EXPLIST are, and have no idea how to look at them in order to see if it has worked.

I do not myself explicitly use "/UNDEF" on the command line, I am using the IDE to write and debug my code.

I do not know if I "need" to switch /UNDEF off. If I knew how to read in a binary-file and access the data without having to do so then I would have already done so.

The values in the binary-file can be such that an UNDEFINED value is present when read into an array. So in the case for these particular routines I most certainly DO want an UNDEFINED value to "happen".

Regards

Marz

[LitusSaxonicum]

When you install FTN95, the installation includes a file FTN95.CHM, which is a searchable Windows help file. In it is information on many things you will find helpful. One of the sections in this document describes compiler options. While it is easier to use compiler options in a command-line environment, you can invoke them when you are compiling through PLATO. The two listing options are described as follows:

/LIST [<filename>] more...
Produces a source listing file. If <filename> is not provided, the name is created by replacing the source-suffix with .LIS, e.g. with FOO.F90, the map file would be FOO.LIS.

/EXPLIST [<filename>]
Generate a listing file containing a symbolic assembler listing. <filename> is the optional name of the .LIS file. /EXPLIST is equivalent to /LIST but causes each source statement to be followed by the assembler statements corresponding to the instructions into which it was compiled.

If you generate a listing file you can look at it using any application that can read plain text files. If you don't understand assembly language, /EXPLIST isn't going to be very helpful.

There is nothing intrinsically wrong with having undefined values in any variable, but if you actually use those values in any conventional sort of arithmetic, you don't have a clue as to what the result will be, and the chance is that your program will produce nonesense. Many programs do this anyway, but it is difficult to believe that it is your intention!

The pattern of bits that signals a value is undefined in a floating point number may be perfectly valid if interpreted (say) as characters, or graphics, but then you need to access the relevant bytes in the right way.

Good luck!

Eddie

[davidb]

[LitusSaxonicum]

David,

Some useful ideas here, and food for thought, but probably too sophisticated for the needs of the original poster. I am certainly going to think about these approaches.

The business of the scope of a variable is far more complex when using modules in Fortran 90 et seq than it was in Fortran 77 and earlier, although even the latter could get you in trouble. (The facilities provided in the newer standards are solutions to problems that I don't have, and some of them produce problems that I never had before!)

Eddie

[MarzAttax]

The post was not "too sophisticated" for me, I understand it well. I am however unsure if anyone has understood my problem "sufficiently".

I have binary data that I read into an Integer*1 array.
Each element of this array is not necessarily a single entity with respect to the function that is accessing it. Many elements may be required to form a number that it requires.

For example, the function may need to extract:

array(73) at bit-positions 3 to 7
and
array(74) at bit-positions 0 to 5

in order to retrieve an 11-bit number.

The problem is that each element of the array may have a bit-pattern that implies "undefined", so when the function reads the data into an Integer*1 the error as stated in the original post occurs.

Marz

[JohnCampbell]

For the code that requires this range of values, don't use compiler options that select /UNDEF.
Once you are confident this code works correctly, why do you continue with /CHECK. I'd recommend using only /DEBUG.

John

[davidb]

You have to store and define 8 bits at a time in your integer*1 array. You can store 6 bits for example with 2 leading bits set to 0.

You should be able to use TRANSFER to avoid the interpretation of a bit pattern as an undefined value.

What form is the binary data in?

Can we see a line or two of code which gives the error?
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl

[LitusSaxonicum]

"Too sophisticated" wasn't intended to be insulting. But your remark:

[MarzAttax]

@JohnCampbell:

When I am confident that some code works correctly I want to continue with /UNDEF because I will no doubt be writing more new code, which I am less confident about.

[MarzAttax]

@davidb

One defining and necessary condition of the program/data is that ALL 8-bits are used.

Here is the line (and associations) that causes trouble:

Header-file Start
Type(Structure)
.
.
.
Integer*1, Pointer :: pstData(
End Type(Structure)
Header-file End

Subprogram Start
!! Passed
Type(Structure), INTENT(INOUT) :: pstTileDataP

!! Locals
Integer*4 :: iByteOffsetL
Integer*1 :: i1Value1L
.
.
.
i1Value1L = pstTileDataP%pstData(iByteOffsetL + 1)
.
.
.
Subprogram End


The value in the array at pstData(iByteOffsetL + 1) is: Z'80'_1 == 128

Marz

[MarzAttax]

Thanks to all who are trying to help with this

[MarzAttax]

@LitusSaxonicum

I believe that my requirements are quite basic

When I examine arrays that are of the Integer 1,2 and 4 bytes nature, I notice the following:

1) 1-Byte: UNDEFINED pattern == Hex(80) == 128
2) 2-Byte: UNDEFINED pattern == Hex(8080) == 32896
3) 1-Byte: UNDEFINED pattern == Hex(80808080) == 2155905152


I Consequently struggle to know how to reply to your statement of:

"If your array variable is integer, then you shouldn't ever get 'undefined' - because all possible bit patterns in an integer*1 (one byte) are valid values (00000000 to 11111111 and everything in between represent the integers from -128 to +127). Whether you set bits yourself, or they are just random 'junk', the combination of bits in an integer*1 is always a valid combination."

Regarding "trying to squeeze that 11-bit combination back into an 8-bit space", the error occurs when I read the data from the Integer*1 array into an Integer*1 local variable, and therefore the functionality of the function does not matter at that point.

I thank you for your time and consideration on the matter


Marz

[MarzAttax]

Further to this problem, I tried putting in the line:

!FTN95$OPTIONS(-UNDEF)

in order to switch off UNDEF for a module, and it "worked". It does however have an undesirable side-effect in that I can no longer debug through that module. Any attempt to F7 into it is ignored, and when I "find" the routine (within the debugger) it returns a window with Assembly-Language therein.

When I remove the line shown abouve, then I am again able to debug the code, but of course the UNDEF problem occurs - lol

Is this "normal" behaviour?

TIA

Marz