intent(out) problem

[jin_li]

this is the relevant piece of the code

subroutine lineclip_polygon(a,na,nna,b,nb,nnb,p1,p2)
!dec$ attributes dllexport:: lineclip_polygon
implicit none
integer, intent(in) :: nna,na,nnb
integer, intent(out) :: nb
real*8, intent(in) :: a(2,nna),p1(2),p2(2)
real*8, intent(out) :: b(2,nnb)


....
end subroutine lineclip_polygon


warning message is

Setting environment for using Visual Fortran tools
df /compile_only /nologo /nodebug /dll /include:"..libfmfm" /check:bounds /traceback /optimize:5 /module:"..libfm" /object:"..exe_release" .toolboxtoolbox.f90
.toolboxtoolbox.f90
.toolboxtoolbox.f90(1659) : Warning: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value. [NB]
subroutine lineclip_polygon(a,na,nna,b,nb,nnb,p1,p2)
---------------------------------------^

what is wrong? I use CVF 6.6 on window XP. It's only a warning, no serious problem, but I'd like to know why.

Thanks a lot for help.


Jin Li

[Xiaoping_D_Intel]

integer, intent(out) :: nb

nb with intent(out) means this dummy argument will be used to pass data from the subroutine back to the calling program. However, in your code it is not assigned with any excplicit valuebefore the subroutine return so the compiler issue the warning.

[jin_li]

you are absolutely right, nb was not assigned to any values.

Thansk a lot! That's helps.

Jin Li

[mecej4]

I wish to warn you about using INTENT(OUT) on non-scalar variables, such as b. According to the Fortran standard, all the components of such a variable (in this case, the entire array) become undefined upon entry to the subprogram.

In many algorithms, it is common to update a few components, with the expectation that those components that were not updated will retain their previous values. Indeed, that's how things worked in Fortran 77 and earlier. With Fortran 9X and later, however, the appropriate attribute for such variables is INTENT(IN OUT), even if the subprogram never uses any of the previous values.

In the interests of efficiency, many compilers, Intel Fortran included, do not usually generate any code to make the INTENT(OUT) components undefined upon entry. However, specifying INTENT(OUT) for non-scalars can create a bug in the source code that is likely to become alive long after its existence has been forgotten.

[TimP]

That's a good point. In the worst case, not only is the entire INTENT(OUT) array uninitialized in the subroutine, the entire unininitialized array, or part of the array which has not been initialized in the subroutine, could be copied back to the caller. The more realistic case is that array elements used in the subroutine will be undefined initially, so that code which depends on initial values will pass garbage back to the caller.

[Jugoslav_Dujic]

Quoting mecej4

In the interests of efficiency, many compilers, Intel Fortran included, do not usually generate any code to make the INTENT(OUT) components undefined upon entry.

...however, some initializations of INTENT(OUT) on entry are mandated by the standard. (Though they're not relevant for Yin Li). Off the top of my head (so I might be wrong), those are:

• Those components of TYPE (Foobar), INTENT(OUT) that have specified default initialization must be default-initialized, in both scalar and array cases
• ALLOCATABLE, INTENT(OUT) variables are deallocated on entry
• POINTER, INTENT(OUT) variables get undefined association on entry