| Nasser Abbasi 2006-05-26, 7:04 pm |
| Hello
"Richard Maine" <nospam@see.signature> wrote in message
news:1hfxy4r.1sv2j76l6cgg1N%nospam@see.signature...
> Nasser Abbasi <nma@12000.org> wrote:
>
> Internal procedures are not compiled separately. Therefore, the odds of
> catching things like this in an internal procedure are far better. It
> still is not guaranteed. I might have seen some bugs resulting form
> uncaught errors in that situation. But the odds are at least better.
>
Ok, you are correct, the Fortran example was using an external proc (even
though it was in the same source file) while the Ada one used an internal
proc.
Here is a Fortran one that is using internal procedure that attempts to
change the loop counter, so that now we have the same type of code. In Ada
we call an internal proc to try to update a loop counter, and in Fortran we
call an internal proc to try to update a loop counter. I hope this you'll
find it to be a better test.
$ cat a.f90
----------------------
PROGRAM MAIN
DO I=1,10
CALL foo(I)
PRINT *,I
END DO
CONTAINS
SUBROUTINE foo(I)
I=I+1
END SUBROUTINE
END PROGRAM MAIN
------------------
$ g95 a.f90
$ ./a.exe
2
4
6
8
10
12
14
16
18
20
Please note that I did not use the intent(in ) in the Fortran internal
proc(), this is by purpose. I wanted to see if the compiler will detect that
a call is being made to a proc which is taking a loop counter as an
argument, where it does not have intent(in) on that argument declared.
I do not think this is too hard for the compiler to check, but I can be
wrong. I would have to assume then that this is a g95 issue where it just
does not do this extra check if it is supposed to be part of the Fortran
standard to try to check against loop counters updates.
thanks,
Nasser
|