forums.silverfrost.com

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

Hello everyone,

I am creating some "generic" subroutines using transfer to move data between actual data type and an array of 1 byte characters.

I found that the use of the transfer function highlighted with a comment (***Error) in the following code doesn't work when I compile in CHECKMATE WIN32 mode, but works fine in DEBUG WIN32 mode.

I get a run time error that the character array is not defined when I run this in Plato. (In the FTN95 Express GUI it just crashes).

Is this a bug or am I missing something? Any help or information would be appreciated. I'm using Version 5.4 of FTN95 (as 5.5 doesn't seem to be available for download yet).

silverfrost · Posted: Mon Jun 28, 2010 11:09 pm Post subject:

Personal Edition 5.5 has been available for some time. Supported customers have had version 5.50 available from the release date.

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

The latest FTN95 Express download only includes 5.4. (This is what I have).

I see from the KB you can install FTN95 Personal (to get 5.5) and then install only the IDE part of FTN95 Express. I will try that.

Will this fix the problem though?

PaulLaidler · Posted: Mon Jul 12, 2010 4:40 pm Post subject:

I am not sure what is going on here.
The effect is apparent in version 5.5.
I will aim to investigate when I can find time.

PaulLaidler · Posted: Wed Jul 21, 2010 3:58 pm Post subject:

Although this is technically a bug it is one of those that does not warrant a fix.

/checkmate (i.e. /full_undef) includes a check for undefined character values and these appear as Z'80'. FTN95 has applied this check before calling the transfer function and has found such a value.

The check is probably not warranted in this case but it does not seem reasonable to avoid this very special situation in the compiler code.

As a user you should use no more than /undef and not /full_undef in this local context. i.e. do not test for undefined character variables within this particular routine.

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

Thanks Paul.

Sorry, I have not visited for a while and missed your posts but I'm very interested in your view.

Are you saying that you can't assume that you won't get hex 80 bytes in your data so /CHECKMATE will sometimes return false positives? Does this apply to all variable types or just character arrays?

If so its just a limitation of the method and can't be fixed without a total re-write of the compiler.

I was able to get the code above working by using an integer array as the "buffer" instead of a character array. However, I realised the concept was not really a good idea (too difficult to understand) and I have abandoned it now.

David.

PaulLaidler · Posted: Thu Jul 29, 2010 7:15 am Post subject:

In fact I ended up by fixing this "bug" in the compiler although is is a very special case.

The reality is that the compiler has to use some value to represent the undefined state for each of the standard Fortran types. This means that, in general use, there will be very rare "random" events that cause the undefined checking to hit this undefined state. It is not surprising therefore that the transfer function is not really a candidate for applying this check.

Anyway, as I say, I have fixed this for the next release so everything should be OK in the present case.