Re: Return value of system call (newbie question)

[Mark Biggar <mark.a.biggar@home.com>]

Torbj�rn Karfunkel wrote:
> 
> I'm executing an external program from within an Ada program by using
> 
>    function OtterCall(Value : String) return Integer;
>    pragma Import(C, OtterCall, "system");
> 
> The program that is called upon, Otter, is called with the syntax
> 
> otter <input-file> output-file
> 
> and the calls look like this (several calls to each are made)
>... 
> Two problems have arisen:
> 1) The first call to otter was executed normally and produced the
> outfile satresult0.oout,
>     but the second call, which I thought would produce the outfile
> tautresult0.oout, produced
>     an outfile named tautresult0.oout0.oout.
>     It seems that some part of the Value string from the previous call
> is appended to the end
>     of the next.  I solved this problem by appending a sequence of
> blanks to the end of the Value
>     strings, but this seems unnecessary. Could anyone give an
> explanation to this behavior?

Yes, the code is reusing a memory buffer to construct the argument
string. But, the routine system probably expects a terminating nul
character on it's input string.  Add a '& ASCII.NUL' to your 
argument or use the To_C conversion call from Interfaces.C.

> 2) The value of Result is 26624. The program executed, Otter, produces
> exit codes, and I would
>     like to get access to this exit code in some way instead of systems
> return value. How is this
>     accomplished? The manual on system says

This will be quite a bit more complicated and not as portable as
using "system" as you will have to duplicate what "system" does 
internally and that varies with what operating system you are
running under.  On Unix/Linux you wil have to do 'fork' and 'exec'
calls and then a 'wait' call to await the termination of the program.
the return value you are looking for is embedded the return value
of the 'wait' call as a bit field.  On Windows what you have to do is
completely different.

--
Mark Biggar
mark@biggar.org