bernhold@qtp.ufl.edu (David E. Bernholdt) (01/26/91)
I've come across an interesting feature ;-) of Sun f77 v1.3.1. There is now a data type named BYTE, which is synonymous with LOGICAL*1. BYTEs are allowed in some, but not all places integers are allowed. They _can't_ be DO loop indices. They _can_ be array subscripts. Apparently due to BYTE and LOGICAL*1 being the same, it appears that _any_ LOGICAL variable can now be an array subscript. Not just things which are specifically LOGICAL*1, but all possible LOGICALs (*2, *4, and just plain)! A side effect of this side effect is that typos such as If ( A(i .lt. j) ) instead of If ( A(i) .lt. j ) are taken without comment and give you completely bogus results. My sample type is pretty easy to spot, but any Fortran programmer can probably imagine nice complex arguments where a misplaced parenthesis is much harder to spot. So... 1) Can anybody think of a way to get the compiler to help identify typos such as my example above? 2) Can anyone with experience writing compilers say if it is realistic to somehow expect that (for example) _only_ LOGICAL*1 be allowed as an array subscript, while LOGICAL and *2 and *4 would give errors? Basically, I want to know if I should consider this a bug which might have a fix or workaround, or as an undesirable feature? Thanks. -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (02/16/91)
In article <1250@orange19.qtp.ufl.edu>, bernhold@qtp.ufl.edu (David E. Bernholdt) writes: > >I've come across an interesting feature ;-) of Sun f77 v1.3.1. There >is now a data type named BYTE, which is synonymous with LOGICAL*1. > >BYTEs are allowed in some, but not all places integers are allowed. >They _can't_ be DO loop indices. They _can_ be array subscripts. > >Apparently due to BYTE and LOGICAL*1 being the same, it appears that >_any_ LOGICAL variable can now be an array subscript. Not just things >which are specifically LOGICAL*1, but all possible LOGICALs (*2, *4, >and just plain)! Have you verified that this is indeed the case, or are you just making an assumption? > >A side effect of this side effect is that typos such as > If ( A(i .lt. j) ) >instead of > If ( A(i) .lt. j ) >are taken without comment and give you completely bogus results. My >sample type is pretty easy to spot, but any Fortran programmer can >probably imagine nice complex arguments where a misplaced parenthesis >is much harder to spot. > >So... > >1) Can anybody think of a way to get the compiler to help identify >typos such as my example above? Compilers can only identify incorrect syntax, not "typos" in which you substitute an unintended yet valid construct for a different intended one. My guess is that, while BYTE and LOGICAL*1 may be "synonymous" in terms of the code and addressing developed when they are used in ways legal for both, declaring an entity as type BYTE would make it legal for it to be used as an array subscript but not to stand for a "logical" quantity. Fortran 90 will introduce user-definable data "types" that, though they may coincidentally be identically defined, they are logically different so that stronger type-checking can be done. > >2) Can anyone with experience writing compilers say if it is realistic >to somehow expect that (for example) _only_ LOGICAL*1 be allowed as an >array subscript, while LOGICAL and *2 and *4 would give errors? > >Basically, I want to know if I should consider this a bug which might >have a fix or workaround, or as an undesirable feature? Sorry, no compiler writing experience, but why on earth do you find it important to use a LOGICAL*anything as an array subscript? This isn't logical. > >Thanks. >-- >David Bernholdt bernhold@qtp.ufl.edu >Quantum Theory Project bernhold@ufpine.bitnet >University of Florida >Gainesville, FL 32611 904/392 6365 -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "I disclaim disclaimers" CANADA | -------------------+-------------------------------------------