#293 run time errors returning 0 to shell

[Brian Tiffin]

#
# Runtime error message example
#
procedure main()
    a := "1" + []
end

runtime-error.icn

Properly reports an error message, but returns 0 as a shell status instead of (what used to be) 1.

prompt$ unicon -s runtime-error.icn -x

Run-time error 102
File runtime-error.icn; Line 12
numeric expected
offending value: list_1 = []
Traceback:
   main()
   {1 + list_1 = []} from line 12 in runtime-error.icn
prompt$ echo $?
0

Success status from an error pass

This didn't occur with rev 5159, which returned status 1, but does with 5628 and 5634, not sure when it broke in between.

[Jafar]

fixed in [r5635]

[Jafar]

Of course this assumes that the child process returns 0 on success, otherwise there is no easy way to intrepret the returned value of 1, but I don't think we need to cover that case here.

[Brian Tiffin]

Not quite right yet. I should have included two sample runs and been more thorough in the explanation, Jafar, apologies.

#
# kill.icn, send signal to PID
#
procedure main()
    write("send signal to kill current process")
    kill(getpid(), "SIGKILL")
    write("won't get here")
end

examples/kill.icn

returns 137 (which is good, bits 0-6 status (signal value, SIGKILL being 9 on my Linux boxes) and bit 7 set as it was a signal death).

prompt$ unicon -s kill.icn
prompt$ ./kill
send signal to kill current process
Killed
prompt$ echo $?
137

the proper exit code

But fails on -x, converting the code to a simple 1.

prompt$ unicon -s kill.icn -x
send signal to kill current process
Killed
prompt$ echo $?
1

Loss of information here.

[Jafar]

I actually thought about returning the exit code of the child process but I wasn't sure if I'd be breaking any previous semantics. I think I was just extra conservative since I don't believe there hasn't been a wide use for the exit code when doing -x. I will go a head and do it, stay tuned.

[Jafar]

Another attempt in [r5636]. This time I actually had to fix the underlying c code. system() was not returning the exit status as documented bit a raw status value instead.

Let me know if this looks better now.

[Brian Tiffin]

Looking great, Jafar. UP docs building without capture warnings now.

Not to complicate your life or anything, but the WEXITSTATUS macros may or may not exist depending on platform. Windows doesn't, as far I remember when I last looked, so you'll probably need a compile time test. #ifdef WEXITSTATUS ... #endif for instance.

[Jafar]

That might not be a bad thing to add. Windows hoever is already covered since this code is unix only.

[Bruce Rennie]

Jafar,

I think (pursuant to my comment in bug 294) that the change of exit(1) to return 1 should be reversed to just exit(1) if you are attempting to pass back to the parent that unicon has found a problem in the compilation process with errors found.

In a similar vein, I would suggest changing the return rv to exit(rv)

As well, change return parsingErrors to exit(parsingErrors)

[Jafar]

Bruce,

Those changes were only to the internal function named "unicon", I just moved the call to exit() the the main() function. i.e unicon() now always returns the value to its caller which in this case passed up by main() via exit().

[Bruce Rennie]

Thanks for the clarification, missed that when looking at the code.