Fortan error not detected

[billaustralia]

I am not sure if this is the place to report this but here it is.

program test
implicit none
if(1.eq.1.and.135)print *, 'Hello World'
end program test

for which the output windows is
Compiling Fortran...
H:Sgastlib est est.f90

test.obj - 0 error(s), 0 warning(s)

if I replace 135 with 135.3 I get

Compiling Fortran...
H:Sgastlib est est.f90
H:Sgastlib est est.f90(21) : Error: The highest data type rank permitted is INTEGER(KIND=8). [135.3]
if(1.eq.1.and.135.3)print *, 'Hello World'
----------------------^
H:Sgastlib est est.f90(21) : Error: The highest data type rank permitted is INTEGER(KIND=8).
if(1.eq.1.and.135.3)print *, 'Hello World'
-----------------^
H:Sgastlib est est.f90(21) : Error: A logical data type is required in this context.
if(1.eq.1.and.135.3)print *, 'Hello World'
-----------------^
Error executing df.exe.

test.obj - 3 error(s), 0 warning(s)

[kdkeefer]

Hi Bill,
I'm not sure it's the right place to post it, but I'm not sure I'm a great expert at answering it either. But it's a holiday in the US and you might not a better one until tommorow.
First, your first statement is in error, as I'm sure you know. Did you run in "debug" mode? Decimal points sometimes confuse compilers, so I tend to use parentheses when concatentating logical expressions with logical operators that use the "dot" form. It also helps me keep reals and integers straight, as do trailing zeros for reals.
In your second test, in which you apparently assign a real literal to an integer variable, you seem to get suitable error messages, including one for the missing logical operation. Years ago there were "student" compilers that were very good at finding errors, but executed code as fast as a mechnical adding machine. Now we all hound compilier writers for speed, interoperability with other languages ease of writing and I guess a few missing error checks are the price.
Regards,
Keith

[Steven_L_Intel1]

Bill,

I'm staring at your code and trying to figure out what it is you want it to do. So far, I am stumped, so it doesn't astonish me that the compiler is also stumped.

Let me suggest reading my Newsletter article on the LOGICAL datatype - perhaps it will be helpful to you. If not, please write back here and explain what you think your IF statement does.

Steve

[billaustralia]

Well I read your article Steve, interesting.

But I just made a coding error in a large amount of new code. I had intended i.eq.135 and left off the i.eq and since I got no error or warning from the compiler, it took me some time to finally find the rather long if statement was not giving the result I wanted. And then I spotted my coding error.

I think the compiler should give an error. 135 is clearly an integer and not a logical variable. No I do not use integers in the way discussed in your article. I have done in vb where it is clearly described in the manual.

[Steven_L_Intel1]

Bill,

As mentioned in my article, and documented in the CVF manual, CVF has an extension that allows for free conversions between integer and logical types. The primary motivation for this is people who traditionally use the logical operators such as .AND. and .OR. on integer values. If you turn on standards checking, it should flag this usage, but otherwise the compiler does not consider it an error.

You may want to run with standards checking turned on - it may help catch future problems similar to this one.

Steve

[billaustralia]

Thanks Steve; have now put that option in.

Also read your article to see how I missed the mention of the option to standard check; answer it is not there.

But I should have realised such an option would be available.

[Jugoslav_Dujic]

In my opinion, this extension creates more problems than it's worth. The only useful part of it is application of operators purely on integer variables:

i = .not.(j.and.k .or. m)

because it's far more readable than standard

i = not(ior(m,iand(j,k)))

(Note that you can't substitute it with standard overloaded operators (i.e. define your own .bnot., .bor. and .band.) because you can't get the priority right -- user-defined operators have the same, highest, priority.)

But free mixing is really insane:

integer:: i, j, k
logical:: b1, b2
i = j.and.b1 .or. (k+b2)

Is it there for historical reasons or what? I'd really like to see it as non-default in future releases (except maybe the operator part).

Jugoslav

[Steven_L_Intel1]

How do you propose that the compiler tell the difference?

Steve

[Jugoslav_Dujic]

Why can't it? -- I'm not very familiar with how parsing/lexing works, but I assume that the parser recursively analyses the expression and knows the type of each subexpression. If so, by my proposition, .AND./.OR./.NOT./.XOR. would be applicable only if both operands are of same type (and produce an error otherwise); arithmetic operators +-/* would be applicable only on integers. I don't see the flaw in that logic -- do you?

Jugoslav

[Steven_L_Intel1]

Ah, ok. That makes sense, but it flies in the face of 30+ years of documented tradition. Still, there may be things we can do to at least give informational "did you really mean this?" messages for the more troublesome cases.

Steve

[Jugoslav_Dujic]

It was more a wishful thinking than a serious proposition (for the start, it would break most of my codes since I'm usually lazy to take a look whether the function returns an INTEGER or a LOGICAL so I use whatever is at hand).

Still, one of my main objections to CVF is that its default settings are too liberal on dubious programming practices. Your mileage may vary, of course.

Jugoslav

[Steven_L_Intel1]

I agree that Compaq Fortran is a bit too liberal at times. When I was working on VAX Fortran, I added a /WARNINGS=USAGE option to have the compiler flag (with an informational message) usage which was accepted by the compiler but often unintended by the programmer, for example, a GOTO into a block (which our F90 compilers simply disallow). It's one of my goals to get this sort of thing into our current Fortran compilers - I think our customers will appreciate it.

Steve