//ACHAR(0) vs //''C

[gelarimer]

Using IVF 9.1 on XP machine.

GetModuleFileName() below returns the nul terminated str:
gszDirBuffer = 'C:DataIVF ModelProg.exe'

An exception occurs in later code if gszDirBuffer is
terminated with ACHAR(0), as shown below, but NO
exception occurs if terminated with ''C.

INTEGER(4) iPos

CHARACTER(Max_Path+1) gszDirBuffer

iret = GetModuleFileName(NULL, gszDirBuffer, (MAX_PATH+1))

! remove 'prog.exe' from gszDirBuffer
iPos = INDEX(gszDirBuffer, '', BACK = .TRUE.)

! ACHAR(0) here causes exception
gszDirBuffer = gszDirBuffer(1:iPos-1)//ACHAR(0)

! ''C here does not cause exception
gszDirBuffer = gszDirBuffer(1:iPos-1)//''C

If I search for the nul char in both strings above using
iPos = INDEX(gszDirBuffer, ACHAR(0)), iPos is the
same for both lines of code.

This is a Win32 program, and ACHAR(0) terminated str
appears to work as intended. The exception occurs in
code that does not appear related to any calcs that
use the ACHAR(0) terminated str.

What is the difference between "//ACHAR(0)"
and "//''C" (no space between the appostrophes)?

Thanks for any commentsinformation.

[Jugoslav_Dujic]

There is no (supposed to be) any difference whatsoever. Personally, I prefer (A)CHAR(0) for portability, but that's just a style issue.

I have a hunch that you have the real problem (silent out-of-bounds write? stack corruption? ) somewhere else, and that slight difference in code reveals it on an unrelated location (remember those pesky old-day run-time errors which suddenly disappear if you (re)move a WRITE statement). Or, please, show us the complete code which exhibits the problem.

(Your code built with IVF 9.1.037 works as expected on my XP machine)

[gelarimer]

Thanks for the reply. I think that "silent out-of-bounds write? stack corruption?" is probably correct, since the exception occurs just after a RETURN is encountered in an f90function. Proplem only occurs when the Release vs of the program is running, but will not occur when the Debug vs. is running.Code is extensive, involving calls to many routines before error occurs, so I will justsort through ituntil the problem is found.

[Jugoslav_Dujic]

Sounds like an awkward bug to catch. Good luck finding it (fixing tends to be far easier).

An idea just struck my mind: if you change all assumed-size (*) array arguments to assumed-shape (:) and then build with /gen-interfaces /warn:interfaces, you will get array bounds passed all round (unless there were type cheatings, in which case you won't be able to build the code). I'm not sure whether it will work, but could be worth a shot.

[jimdempseyatthecove]

Your code does not protect against the possibility of no ''

! remove 'prog.exe' from gszDirBuffer
iPos = INDEX(gszDirBuffer, '', BACK = .TRUE.) 
if(iPos .gt. 0) then
gszDirBuffer(iPos:size(gszDirBuffer)) = ' '
    gszDirBuffer(iPos:iPos) = ACHAR(0)
else
continue! put break point here

endif

Jim Dempsey

[jimdempseyatthecove]

Also,

You could potentially have 'C:foo' or 'LPTxyz' as well as 'FOO.EXE'

Jim Dempsey

[gelarimer]

Thanks for the replies Jim.

GetModuleFileName(NULL, gszDirBuffer, (MAX_PATH+1)) should always return the path of the current process when the hModule = NULL.Since thecurrent process will always be My.exe, then the Fully Qualified Path (gszDirBuffer)should always be in the form "DriveLetter:~My.exe". Or, am I missing something?

[jimdempseyatthecove]

>>should always be in the form "DriveLetter:~My.exe".

Or

"ServerShare~My.exe"

And on NT (XP, Vista) there are some other special names that can appear in place of drive letter or server. As for your case I believe your code is correct in assuming

"(unknown)My.exe".

But you should also provide for

"(unknown)/My.exe"

This is to say test for either "" or "/".

Jim Dempsey

[gelarimer]

Thanks Jim.