Is it possible to exclude one intrinsic funtion for a console app or make user library function used first

[Dean_M_1]

Hello, first time using this forum

I am migrating an application for my company which consists of about 250k lines of code, from Solaris 10 unix to Windows 2012 using Intel Fortran/C+++,  the history of this code is it is a structural analysis program for piping, the history of the OS it has ran on is

CDC OS=NOS

CDC OS=NOS/VE

Solaris OS=2.8 unix

Solaris OS=2.10 unix

Windows 2012  OS currently migrating to from Solairs 2.10 unix

In the NOS fortran compiler, there was a function called EOF to detect if the file was at end of file or could still be read), fortran 66, forward about 8-10 years is was migrated still to CDC (Control Dara Corporation) to NOS/VE (a nice OS but CDC is out of business), next migration in 1995 was to SunOS version, then moved to Solaris 2.8, both on SUN hardware, we developed an equivalent EOF function since we went from NOS/VE to unix since the SUN compiler did not have an EOF function, the last system this code was migrated to was Solaris 10 on an M4000 using sunstudio 12.3, we still used the EOF function in a static library on SUN to emulate the EOF function as it was on NOS, we used it as (assuming stdin), now we are in the process of migrating this from Solaris 10 unix to Windows 2012 to be a console app ran by perl scripts

if (eof(5) .ne.0 ) goto 70

or

if (eof(5) 300, 200, 300

What I have assumed and tested is Intel fortran 2016 (which I am using integrated with MS Visual Studio 2013) has an EOF function but it is if a logical function, I have approx. 198 calls to EOF and since this is QA software I want to make as little changes as I have to, so if there a way to exclude one function in the in the intrinsic function library or to insure it reads from the static library we have used for year on UNIX to insure  it calls our EOF function in our static library instead of the call to EOF in the intel fortran 2016 intrinsic function library, one reason is there are still functions in the intrinsic function library I still want to use and are part of our version of EOF like ftell, fstat and others for other routines not related to EOF

Basically I  want to insure it will call our library function EOF first instead of the intel fortran 2016 intrinsic funtions first without excluding the entire instrinic function library. The reason not to convert, is this code is QA (Quality Assurance) code used for Nuclear plants that the less changes made, the less mistakes that can be made, we have a over 300 benchmarks that runs different piece of the code to insure the answers on the previous version or previous platform match or within limits to verify the application. I hope this is something I can change in Visual Studio 2013 which has intel fortran 2016 integrated, hopefully something to be changed in the properties of the project with the linker or even the fortran compiler. Remember excecpt for 1 major app, there are 3 apps still writtend in fortran 66, still using holleriths but has been 64 bit since going to Solaris 10.

I hope someone nows the answer to this email, my only alternative I have found is to rename our EOF function to IEOF and change the 198+ lines of code which call EOF to minimize changes, typos are always a problems

[TimP]

This looks like an ordinary Fortran question.  If you put your function as an internal function in a USE file with CONTAINS, there should never be any attempt to find it in linked libraries.  If it is a C compatible function, you should give it an explicit interface with iso_c_binding, and take care to link it before anything which might have a like named system function.  In Fortran 77, if you didn't declare it EXTERNAL, you were depending on implementation dependent behavior.

[Dean_M_1]

A lot of it is still f66 code, I used module to make all my c i/o compatible so it could pass char, real, int and not dependent on variable passed and used reference but you care to give me example, out EOF routine is a fortran function

[Dean_M_1]

Found fix for what your saying, thanks