forums.silverfrost.com

[wahorger]

I use the compiler to help keep me honest. I collect all the routines and MAIN's in one file, and compile it. This let's me check for missing arguments, incorrect data types, etc.

I use a lot of TYPE's. So imagine the surprise when I ran a CHECKMATE version of my SW and it discovered, at run-time, a mistake in the TYPE being passed as an argument. My compile step to let the compiler check for me was completely error free. I ran some possible examples through PLATO and the compiler will detect some errors, but not across the module boundaries.

On reflection, it made sense to me that a new data type would be more difficult to detect as an error as if it were one of the elemental data types. On further reflection, though, I said to myself "Well, if the incorrect type can be found at run-time, then all the information to make this comparison is available at compile time."

So, I wondered if there were other's who might have a similar need to mine and would be in favor of some additional compile time checking. If that is at all possible. Or, is there another way I'm missing?

[mecej4]

The compiler can check an actual argument list for correct types if it has available to it a complete interface in the same program unit as the one containing the call, or if the subprogram heading and dummy argument declarations are available in the same file. I feel that the description you have given is rather broad, and I should prefer to see actual code that does what you described.

Consider this example, with arguments being passed in the wrong order.

[wahorger]

Yes, this works for intrinsic types. The following code does not generate a compile time error, but will throw an exception when compiled/run as CHECKMATE.

[JohnCampbell]

I expected the following code would fail with FTN95, but it compiled with no errors using ver 8.20.0 ?
gFortran warns of a possible error.
This is my typical approach to address this problem.

[mecej4]

Curioser and curioser!

Even with CALL DEFG(TYPE_A,TYPE_B) instead of CALL DEFG(TYPE_B,TYPE_A), the first program that you showed would be in error unless the SEQUENCE attribute is included in the derived type definitions. In that case, FTN95 /checkmate does not detect the error even at run time.

[wahorger]

I removed the SEQUENCE just to make it shorter. That made no difference anyway. I don't expect these kinds of examples to necessarily produce good results. Just illustrate an error of one type or another.

That said, John, the MODULE is fine, but the issue I'm working is the call to DEFG with the arguments reversed. Not solved by the MODULE. However, an INTERFACE will solve the problem. I implemented that in one of the complex routines just to make sure I got the arguments TYPEd right in each of the calls...

I had expected the compiler to complain, and it didn't, so I went away doing more work, thinking all was well. In my case, SEQUENCE is used, and the desired TYPE was first up (nested) in the data structure that was being passed. And was /RELEASE, so no errors. It wasn't until I had to run a /CHECKMATE version of the code that the error was revealed.

[JohnCampbell]

Interesting, intrinsic types appear to be tested but not derived types; based on the following example extension

[PaulLaidler]

Runtime checking for matching argument types can sometimes go wrong (giving false error reports or missing errors). Equally there are some really messy situations where FTN95 simply makes no attempt to check the type of the arguments.

I would need illustrative sample code in order to work out this particular case.

[wahorger]

Paul, I'm not all that concerned about run-time checking for individual elements of a TYPE. Whatever /CHECKMATE is doing for seeing if the name of the TYPE is the same between modules at run-time would satisfy many, if not most, occurrences.

I was more concerned about the compile time check. Again, not the individual elements of the TYPE, but even just the NAME of the type should be enough.

The example I gave illustrates that a compile time check is not performed. The fact that the run-time error is trapped would suggest that there is sufficient information at compile time to make that check.

If you need a more detailed example, I'd be happy to try and gen one up. I'd just need to know what kinds of examples you'd need. And if I am unable to do so, perhaps someone else can weigh in with examples that might help.

Bill

[PaulLaidler]

Bill

Sorry but I missed the significance of your example.

The presenting fault is that the call to DEFG from the main program requires an interface for DEFG in the code. In other words the given code is not correct Fortran.

I have not tested this but if you include the required interface then everything should work as expected.

[wahorger]

Paul, thanks.

Yes, with the proper interface, the compiler does catch the error.

I had hoped that the compiler could/would without this, since it is in the same compilation module, similar to what happens when one has errors in intrinsic types.

In my example, if you change TYPE_A to INTEGER, and TYPE_B to REAL throughout, then compile it, the compiler will tell you that you had a difference in the argument types.

[PaulLaidler]

Bill

Strangely the converse might be better. Sometimes the fact that FTN95 remembers some things from one independent program/routine to another in the same file can cause problems and it might make more sense and be simpler for compilation process if this were not the case.

[mecej4]

Consider the following variant of Bill's test program:

[wahorger]

Paul, I have experienced exactly that behavior a couple of years back. I wish I could remember what it was. Simple to just break the multiple modules into separate files, so I think that is what I did.

I'll be OK with whatever course of action (or inaction) you decide to take.

Bill

[PaulLaidler]

mecej4

There may be a fault in gFortran. For me gFortran also gives an error report when SEQUENCE is omitted.