A confusion with START_PROCESS@ description in on-line help?

I used the subroutine START_PROCESS@ as a function (according to on-line help), see: https://silverfrost.com/ftn95-help/control/h_start_processa.aspx

My code for it (as a function) was:

INTEGER FUNCTION txt_sgf ()
    IMPLICIT NONE
    INTEGER*4 txt_sgf, button_grey_SGF, I
    COMMON/txt_2_sgf/button_grey_SGF
    I = START_PROCESS@('GEODBNT.EXE','')
    txt_sgf = 2
END FUNCTION txt_sgf

It worked somehow, but when the external executable finished its work and I pressed exit in external EXE, I got a run-time error for my program which invoked the external process!

So, since it is declared as a INTEGER FUNCTION START_PROCESS@ in the on-line help, I added EXTERNAL STATEMENT for the function.

When I compiled it, it failed with the reason that I cannot use EXTERNAL statement with a SUBROUTINE!

Based on this, I cancelled the EXTERNAL STATEMENT and used the CALL order for the START_PROCESS@ as follows:

INTEGER FUNCTION txt_sgf ()
    IMPLICIT NONE
    INTEGER*4 txt_sgf, button_grey_SGF
    COMMON/txt_2_sgf/button_grey_SGF
    CALL START_PROCESS@('GEODBNT.EXE','')
    txt_sgf = 2
END FUNCTION txt_sgf

Now, everything works fine (no run-time).

QUESTION: What is true - the on-line manual description that START_PROCESS@ is an INTEGER FUNCTION or the START_PROCESS@ is an internal subrouitine (it appears true based on my experience), which needs to be called by CALL order?

Martin

Martin,

I use START_PPROCESS@ and have used it as a subroutine for years. I checked in FTN95.CHM fpr v8.50 and it is definitely listed there as an INTEGER FUNCTION. I'm sure that's wrong. I don't know why I would have used a subroutine call if it was always an integer function, as I am an avid reader of the documentation. Perhaps Paul can tell us if it has been changed recently.

Sometime FTN95 routines can be used as functions or subroutines. Certainly I have used USE_RGB_COLOURS@ both ways without a problem. The difficulty with a subroutine is that it does not return an error code in the way that a function does, so perhaps this is why a change has been planned that has made it to the documentation and not to the compiler !!! An error code would tell the calling program if the other process was launched.

Eddie

Thanks Eddie for your info! You know, when I want to use something new, I always look to documentation how to use it.

And when there is wrong/confused description, then it costs me useless additional time to find out where the problem is hidden. Thanks again!

Martin,

I have seen this before. In this case you need to include the definition of start_process@ in the function/subroutine which calls it.

For example:

 integer function call_back_for_exe1()
  include<windows.ins>
  integer i
  integer start_process@     !##### Must include this declaration
    i = start_process@('exe1.exe',' ')
    call_back_for_exe1 = 1
  end function call_back_for_exe1

The F2008 standard intrinsic EXECUTE_COMMAND_LINE is also available.

Ken

My experience is: If you access a real subroutine as if it were a function, it will likely crash the program. Or, if you declare an INTEGER function as if it were a REAL function, usually a floating point stack overflow.

However, if you CALL any function, it will not crash. It likely won't give you any real answer (after all, it is a function and is expected to return a specific KIND of value) but it will not crash.

And, depending on what you INCLUDE or USE, it may or may not give you a compile time error

It is clear from the documentation that START_PROCESS@ should be declared as an integer. Specifically, the declaration should be

INTEGER,EXTERNAL:: START_PROCESS@

You cannot just declare it as EXTERNAL, then use it as a function. Just declaring it as EXTERNAL implies it is a SUBROUTINE (you have not given it a KIND at that point). If you then use it as if it is a function, the compiler rightly gives up.

To understand why things crash, it becomes clearer what is going on, internally, if you read the assembly language generated for a simple function call and a subroutine call. Most people won't, and don't. But, I'm a glutton for punishment, so I look. Fascinating!

P.S. Don't look at /CHECKMATE code. Too complicated; stick with looking at /RELEASE. No error checking, much more straightforward.

Thanks to all! I will experiment as outlined by Ken and wahorger.

START_PROCESS@ is an INTEGER FUNCTION. It returns -1 if the process cannot start otherwise it will return the processes exit value.

I think you can call any integer function as though it was a subroutine provided it is declared correctly. You cannot do that with a real function because it would mess up the floating point stack.

Robert,

this was my confusion. I declared the function START_PROCESS@ as EXTERNAL only (should be INTEGER, EXTERNAL as wrote wahorger), therefore I had problems (compiler message was: you cannot declare a subroutine). So, based on this compiler´s message I removed any declaration for it and just used CALL command to START_PROCESS@. And - it worked problem free.

But now, I amended this in such way as wahorger wrote and it works fine. Also I tried Ken´s approach and it also works fine.

Finally - I must ask (in this connection) the following general question:

Can I use the CALL command for any of internal procedures which are declared as functions? (of coarse - in such case I do not get the result, success or failure)

As I said previously:

I think you can call any integer function as though it was a subroutine provided it is declared correctly. You cannot do that with a real function because it would mess up the floating point stack.

I understand it, Robert - thank you!

Just I wanted to clarify the fact that I had NO declaration for the function START_PROCESS@ at all (I removed the declaration EXTERNAL which was anyway INCOMPLETE and ERRONEOUS, since there was missing the word INTEGER as wahorger noticed - should be INTEGER, EXTERNAL). So - in this situation (only with word EXTERNAL in declaration) the compiler said - you cannot declare a subroutine as a function. Now - I know the reason of the compiler´s compliant - missing word INTEGER and therefore compiler assumed that I use a subroutine.

Based on compiler´s message I REMOVED the declaration EXTERNAL and just used the CALL for the function (with NO previous declaration for START_PROCESS@). It worked problem free. This was my question, because you wrote ...provided it is declared correctly... and I had NO declaration for it at all and it worked.

But anyway - you clarified me a lot for the future, thank you again!