Compiler behaviour regarding Pipes between C# and IVF 12.1

[François-Xavier]

Dear all,

Few years ago, I had a problem with Intel Fortran 11.1 regarding memory pipes and C#. I found myself a difference with Intel 11.1 regarding the number of characters that must be filled into pipes before Fortran code reacts.

Today, i am using IVF 12. Behaviour regarding pipes changed, again. In fact, contents of the C# pipe seems OK but I have problems retrieving pipes contents. In fact, what i have noticed is that there is no corruption if i make a small loop reading the pipe. Problems comes when i perform a READ, then doing something else and the come again into the READ.

I have created a full example for you. If you compile C# and Fortran App and gives the C# the Fortran App full path into argument you will be able to run it with the DummyText.txt file i try to send through pipes.

What you will see is that the textfile (output.txt) received by the Fortran is OK except for one line.

If you remove the EOF check of my code, this bug disappear... What is strange is that it happens with a EOF check, but it can happen with other treatments, such as calling a C function, calling another Fortran function,...

Files: https://drive.google.com/file/d/0B-SwVOiKUpbhc0tGRFFSVXdfWUE/edit?usp=sharing

Password of this file is: Intel_Thx_All

Many Thanks,

We are currently still using IVF10 for some apps regarding pipes. We really would like to migrate.

F-Xavier

[François-Xavier]

Dear Intel Forum,

After several tests, the EOF detection in memory pipes seems to be the weak point of the compiler:

• If I Add an END statement in the READ, EOF is not detected: READ(XDAT1,5,ERR=996,END=990) Z200CARI -> This don't work in IVF10
• If I Add an EOF check before the READ, pipe is corrupted. --> This work in IVF10

So currently, I search a workaround for detecting the EOF. This can open the discussion.

UPDATE: It seems that, within the READ statement, the ERR statement is triggered with error 39 when reaching the end of file in pipe. I have found a workaround focusing on error code 39...

Sincerely yours,

F-Xavier