Strange behavior using a module which uses another module

Hi,

it's me again :-) I'm testing my function libraries against a standard
library and I don't understand what's happening. The libraries I
developed are called md_Jacobi and md_Global_funcs. The standard
library function is dgamma.f from SPECFUN.

module md_Global_funcs
contains
....
real function lgamma(x)
....
write(*,*) 'foo' ! Keep in mind this instruction...
....
end function lgamma
....
end module md_Global_funcs


module md_Jacobi
use md_Global_funcs
.....
end module md_Jacobi


program main
use md_Jacobi
external dgamma
.....
do i=1,10
write(*,*) 'x', i, 'dgamma', dgamma(real(i)), 'gamma',
gamma(real(i)), 'n!',factorial(i), lgamma(real(i))
end do
.....
end program main

1) I was surprised that main was able to access gamma, lgamma and
factorial, defined in md_Global_funcs, since main only uses md_Jacobi
and not md_Global_funcs. However, I looked at MRC and found that since
md_Jacobi uses md_Global_funcs, then main has access to it also. Is it
possible to let a program unit A use a module B, without having access
to any module used by B unless explicitly used by A?
2) compiling with EFC, I get the following error:

forrtl: severe (40): recursive I/O operation, unit -1, file unknown
Image PC Routine Line
Source
main 40000000000C6190 Unknown Unknown
Unknown
main 40000000000C2620 Unknown Unknown
Unknown
main 40000000000B5050 Unknown Unknown
Unknown
main 4000000000044D20 Unknown Unknown
Unknown
main 4000000000022D00 Unknown Unknown
Unknown
main 4000000000005E40 Unknown Unknown
Unknown
main 400000000000D450 Unknown Unknown
Unknown
main 4000000000002C80 Unknown Unknown
Unknown
libc.so.6.1 20000000003CDC50 Unknown Unknown
Unknown
main 40000000000029C0 Unknown Unknown
Unknown

due to the "write" instruction in lgamma. Why is the compiler
complaining about a recursive I/O? How can I use print/write
statements to debug my libraries without incurring in this error?
Thanks,

Best Regards,

deltaquattro

.

Relevant Pages

  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... If you are claiming there is a reason to avoid the mechanisms the standard provides to allow portability then it is up to *you* to prove your point, not up to others to disprove it. ... but you can hardly blame the consequences on the Standard headers. ...
    (comp.lang.c)
  • Re: About libraries and headers
    ... You are assuming that the contents of a header file are closely ... The standard header files ... which are used to build the libraries. ... compiling them would not generate any ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... want to have standard headers included in their own headers which ...
    (comp.lang.c)
  • Re: comparing doubles for equality
    ... AFAIK there is no ANSI/ISO standard for it. ... Fortran 95 seem to have some built-in operators but it's not clear ... LIA,GIA,ICE libraries for interval methods in C++ from Delisoft ... Actually I've been for quite some months proposing getting together ...
    (comp.programming)
  • Re: "Criticism of the C programming language ??????"
    ... "that's not in the standard, ... rewrites of the compiler. ... PH> They got all the compiler vendors to agree to a common ... or graphics libraries or threading libraries, ...
    (comp.lang.c)