Allocatable Components of Derived Type Incorrectly Implemented by Lahey

[blamm]

I'm a registered Lahey user, currently at LF Fortran 7.1, but have a problem that I consider a bug and Lahey does not.

I want to know your opinion, especially those of Terrence Wright and Richard Russell.

Suppose a program is built, using any compiler switches you like, resulting in an executable with an assignment thus:

a(7:12) = c(7:12)

where a array is declared as real, dimension(12) and c array is declared as real, dimension(6).

Now, regardless of the Lahey switches used to build the executable, there would be a runtime error on the subscript bounds of c array in the above assignment.

Now suppose the following assignment is made:

a(7:12) = b%c(7:12)

where a array is real, dimension(12), b is a scalar derived type with an ALLOCATABLE component c which is allocated as ALLOCATE( b%c(1:6) ).

If you compile with ANY switches you like ( as long as of course the executable successfully builds), then in my opinion the above assignment should cause a runtime error due to referencing out-of-bounds subscript on allocatable component c.

However, the latter assignment SUCCEEDS, an assignment is made and the program continues on its merry way executing with GARBAGE in a(7:12)

Lahey insists this is not a bug, but rather a product suggestion. Lahey received the "product suggestion" in 1999.

In my opinion, this is NOT a DEBUG issue, I believe it is an issue of CORRECT IMPLEMENTATION of allocatable components of derived types.

Lahey's utterly lame suggestion was to make the allocatble component c NOT allocatable, but rather a component of fixed dimension, which completely obviates the usefulness of allocatable components to begin with!

What's your opinion? Should the latter assignment be permitted to "quietly" succeed?

Brian E. Lamm

[blamm]

Thanks Mike Prager.
In fact, out of bounds subscript references do not have to elicit an error for ANY array reference, according to Lahey, whether it be a component, allocatable or not, of a derived type, or any other array object or sub-object. Lahey told me, however, the out of bounds array reference WOULD have been detected had the component been statically allocated (with the appropriate debug switches set). The dynamically allocatable feature is precisely what I require, however.
I made the fatal ASSUMPTION the standard would not allow access or reference to an array sub-object part that DOES NOT EXIST. MY mistake. I look bad now, but I'll be better off for it in the future.
I also wrote: "Now, regardless of the Lahey switches used to build the executable, there would be a runtime error on the subscript bounds of c array in the above assignment", which was a(7:12) = c(7:12). That, too, was an incorrect statement, there will be runtime error only if appropriate debug switches are invoked.

Brian E. Lamm

[tzeis]

There are both historical and performance reasons why bounds are not always checked.

Historically, programmers used to indicate that a dummy argument was an array by dimensioning it with a size of one. The actual size of the array was passed in as another dummy argument. There are literally millions of lines of existing code that do things this way, and all this code would break if bounds were always rigorously checked.

Programmers also used to play tricks using arrays in conjunction with COMMON and EQUIVALENCE. They were nonstandard, but the usage was so pervasive that compiler vendors were forced to accomodate them.

The performance reason is obvious - if your program always checks array bounds at every array reference, your performance will take a hit. The authors of well constructed and debugged code know that there is no possibility of their arrays going out of bounds, and forcing checking in these circumstances is a disservice.

[blamm]

Tim, you wrote: "The authors of well constructed and debugged code know that there is no possibility of their arrays going out of bounds".

The operative fragment is "and debugged code". What you have stated is a tautology. Array objects or sub-objects that are allocatable components of derived types CANNOT BE DEBUGGED by Lahey for "arrays going out of bounds", thus your tautology.

So, Tim, tell me, how IS one to provide debugged code when the debugging has NO HOPE of capturing "arrays going out of bounds" blunders to which I referred in the original post?

Certainly NOT the Lahey "compiler" debugger. In my case I had to notice subtle inconsistencies in results.

You also wrote "and forcing checking in these circumstances is a disservice". I don't RELEASE debug executables, I release exe's that have been debugged, in so far as possible, and then build OPTIMIZED exe's for release. So, again, it's NOT a diservice to make a DEBUG executable labor "hard" and "slowly".

Brian E. Lamm