Must pad character array with null value when trying to open file (v17 Build 20160721)

[bluequartz]

Here is the line of offending code:

nmlname = trim(tmppath)//EMsoftnativedelimiter//'test.nml'//char(0)

open(dataunit, file=trim(nmlname), status='unknown', delim='apostrophe',iostat=istat)

When compiled in "Debug" mode (No optimizations) the code works as one would expect.

When I compile in "Release" mode I get the following run time error:

C:\Users\mjackson\Workspace\EMsoftPrivate-build\Release>Bin\HDFtextfileTest.exe
 nml file opened with iostatus            0
 nml written with iostatus            0
 writing filename = <C:\Users\mjackson\Workspace\EMsoftPrivate-build\Release\EMs
 oft\Testing\Temporary\HDFtest_nmlfile.h5>, has length           99
 cstring : <C:\Users\mjackson\Workspace\EMsoftPrivate-build\Release\EMsoft\Testi
 ng\Temporary\HDFtest_nmlfile.h5 > has length          100
forrtl: severe (43): file name specification error, unit 55, file C:\Users\mjackson\Workspace\EMsoftPrivate-build\Release\EMsoft\Testing\Temporary\test.nml[][][]
Image              PC                Routine            Line        Source
libifcoremd.dll    00007FFF8695C77C  Unknown               Unknown  Unknown
libifcoremd.dll    00007FFF8698861E  Unknown               Unknown  Unknown
EMsoftHDFLib.dll   00007FFFA49AEC57  Unknown               Unknown  Unknown
EMsoftHDFLib.dll   00007FFFA49AE1D4  Unknown               Unknown  Unknown
HDFtextfileTest.e  00007FF712011851  Unknown               Unknown  Unknown
HDFtextfileTest.e  00007FF712013CDD  Unknown               Unknown  Unknown
HDFtextfileTest.e  00007FF71201465B  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFFB9548364  Unknown               Unknown  Unknown
ntdll.dll          00007FFFBBB35E91  Unknown               Unknown  Unknown

Note the unprintable characters at the end of the file path. I come from a C/C++ background and this was typically a sign that we did not null terminate our strings. The original author of the code swears that we do not need to null terminate strings in FORTRAN. This code also works just fine in GFortran.

Just looking for some clarification on whether I need to null terminate my character arrays that are really file paths?

This is on windows 10 with Visual Studio 2013 Update 5, IFort v17 Initial Release and CMake driven build.

Here are the standard Fortran Flags:

/W1 /nologo /fpp /libs:dll /threads /assume:byterecl

Added Debug flags:/Od /debug:full /dbglibs

Added Release Flags: /O2 /D NDEBUG

Thank you for any help or information that can be provided.

[andrew_4619]

The file name on the open statement is not a C string the null termination is not needed. The trim() is also not needed as nmlname will be padded with white space and the open will ignore those.

Not sure what the crash is though, trim only removes whitespace so the null termination may be the cause of the problem.

[bluequartz]

Right, so just to be clear, in DEBUG mode, I do NOT have to add the //char(0) for the program to run

In RELEASE mode, I MUST add the //char(0) to the code for the code to run properly.

Is this a compiler bug? Optimization bug? Bad Code gen?

[andrew_4619]

Post  the source of a small reproducer, it is hard to know what the problem is without seeing some code.

Also try release build with optimisation switched off. 

[Steven_L_Intel1]

You should never nul-terminate strings passed to OPEN, and in fact doing so is an error. If it works in gfortran it's by accident.

[bluequartz]

Right. It FAILS with IFORT if I do NOT put the null-terminate character. Everyone agrees that this is WRONG but the fact is that if I leave it OFF then the OPEN call fails (when built with Optimization). The code works correctly when there is NO optimization.

Lets review:

! THIS CODE WORKS with GFortran and ifort in debug but fails
! with ifort in release. This is valid Fortran 2003 code
nmlname = trim(tmppath)//EMsoftnativedelimiter//'test.nml'

! THIS CODE WORKS with ifort in Release mode
nmlname = trim(tmppath)//EMsoftnativedelimiter//'test.nml'//char(0)

So I will assume this is an optimization bug in ifort?

[Steven_L_Intel1]

I reserve judgement until I see a complete test case. My guess is that you have an uninitialized variable in there somewhere.