FP Stack fault in /CHECKMATE

There are more things in heaven and earth, John, than are dreamt of in your philosophy. Now who said that?

The point is that the error message, while true, is unhelpful to a user who has no knowledge of the workings of the compiler. Would IMPLICIT NONE show up the error? Maybe, but a programmer declaring RGB@ to be REAL would also get it. Using the appropriate INCLUDE at least makes sure that the types of all Clearwin+ entities are correctly declared, whether they are used or not.

The floating point stack fault may, indeed, result from FTN95 generating code that upsets the x87 stack, but it can also be generated by the programmer making a mistake.

Eddie

In pointing out the symptom that caused the program not to function, and in protecting the computer from side effects such as destabilizing Windows, Paul & Co have done their job. It's a cultural thing, but I have sensed in the past that whereas we Fortran users see this as a crash, a crash means something else at the compiler programming end - what has been produced is a sensible and proper report and conclusion to trapping something wrong. The fact that it is written in Klingon doesn't mean that it isn't clear to Klingons.

The deep gulf is the result of the lack of a dictionary-manual that explains what it all means, perhaps giving hints on where to look and what to do about it. I'm not sure that a homily on what a bad boy or girl or whatever you've been really cuts it nowadays in the absence of corporal punishment. On the grounds that FTN95.CHM is hard enough to get through, perhaps the answer is another file like CWPLUS.ENH (That was intended to be a serious suggestion).

I'll make a couple of suggestions for it:

1. Floating point stack fault

(a) You passed a function to a subprogram without declaring the type of the function correctly when necessary. (NB, Clearwin+ routines are not intrinsic functions). (b) Something went wrong with FTN95 (rare). (c) It is devilry. Exorcists can be found via Google.

2. Floating point divide by zero (floating point coprocessor fault)

(a) You divided something by zero. (Win32). If you test all denominators against zero, you will get compiler warnings, but can trap this condition for yourself. An alternative is to test ABS(denominator) .LT. TINY(denominator), which doesn't give a compiler warning but does do the test. (b) You divided something by an uninitialised static variable, (because FTN95 sets those to zero). (c) It is devilry. Exorcists can be found via Google.

The serious point is that there's no middle ground document to explain what some of the more arcane error messages actually mean. Perhaps there should be. Perhaps it's up to the user base. You know who that means.

Eddie