undef test on a read from a probably corrupted file

hi,

i have the following block of code that i was unable to use /UNDEF on under ftn32 (because of the negative address problem) but i can use /UNDEF under ftn64:

	IF( IREV.GE.462 ) THEN
      AZ%CHSOU(:) =  ICHSOU(43:72)
      AZ%CHFX(:)  = ICHSOUF(43:72)
	  READ (NU, IOSTAT=IOS)  AZ%CHSOU(43:72), AZ%CHFX(43:72)
	  IF( IOS.GT.0  ) THEN
	    IF( IREV.EQ.462 ) THEN
	      BACKSPACE (NU)
          AZ%CHSOU(:) =  ICHSOU(43:72)
          AZ%CHFX(:)  = ICHSOUF(43:72)
        ELSE
          GO TO 98  
	    END IF  
	  END IF	
	END IF

and I get an IOSTAT=158 (which indicates that there aren't enough values stored in the file being read at that record which I happen to know is because the record wasn't written originally) but before the test gets used that invokes the 'backspace' command, i get an 'UNDEFINED Variable/function' error under the 64-bit debugger on the READ statement.

I can examine all the variables involved and none of them are 'UNDEFINED', so i can only assume that the UNDEFINED values are in the internal READ function.

I imagine that, as the 'inline' !FTN95OPTIONS command isn't functioning under FTN64, i will have to split the source file and compile that particular routine without /UNDEF?

But, i wonder if there's some other 'sneaky' way for treating UNDEFINED values as 0 (or some other specific value) when they are encountered during a READ (or other internal function)?

K

Kenny

I would need more information before I could comment on this.

Can you construct and post a short program that runs and illustrates the problem?

not easily. It only happens with a specific datafile. I can try to isolate the particular subroutine and see if that fails with a 'wrapper' opening the datafile but it may require lots of module for it to successfully link...

I'll let you know...

K

ok, i've sent you a zip file via 'hightail'.

just unzip to a new folder and

sdbg64 new1

it should crash at the relevant point...

k

should this code work under /undef?

INTEGER(KIND=7) :: I7=0 INTEGER*4 IKINDSIZE

INQUIRE(IOLENGTH=IKINDSIZE) I7

it returns 4 or 8 into IKINDSIZE under normal usage but claims that I'm trying to call a subroutine as a function(or vice versa) in the debugger on the INQUIRE line...

K

Kenny

I have logged the first issue for investigation.

I have not been able to reproduce the problem with INQUIRE and I am assuming that it has already been fixed for the next release.

Kenny

The problem with INQUIRE may have been fixed in the interim downloads provided here... https://forums.silverfrost.com/Forum/Topic/3780.