abort() in conio won't work

[robsimmons]

I added abort() to conio as part of the fix to #5 - either the bytecode compiler needs a primitive function to call to raise SIGABRT or we need to modify the bytecode with a primitive "raise SIGABRT" bytecode that doesn't have a good analogue in Java bytecode.

However, I must not have rerun the regression test, because this conflicts with stdlib's abort() and causes many regression tests to fail needless. I could just change this to prim_abort(), I suppose? Or should I revisit this corner case in the bytecode compiler?

[frankpfenning]

I am not sure abort() should be in conio. We already have assert as a language primitive, and error to signal errors as a language primitive.

I think there is already or should be a function in the runtime system c0_abort. Can you remind me why we would need a special function? Or perhaps discuss it tomorrow in person.

On Sun, Dec 16, 2012 at 11:19 AM, Robert J. Simmons < notifications@github.com> wrote:

I added abort() to conio as part of the fix to #5https://github.com/frankpfenning/C0/issues/5- either the bytecode compiler needs a primitive function to call to raise SIGABRT or we need to modify the bytecode with a primitive "raise SIGABRT" bytecode that doesn't have a good analogue in Java bytecode.

However, I must not have rerun the regression test, because this conflicts with stdlib's abort() and causes many regression tests to fail needless. I could just change this to prim_abort(), I suppose? Or should I revisit this corner case in the bytecode compiler?

— Reply to this email directly or view it on GitHubhttps://github.com/frankpfenning/C0/issues/30.

[robsimmons]

It's a corner case with the VM - we need to be able to tell the bytecode how to raise SIGABRT. This used to be done via INVOKENATIVE and a call to error(), but the resolution #5 meant that we couldn't do it that way anymore.

Error behavior - comparable to the stdlib.h exit(1) - is semantically closest to ATHROW. Assertion failure - comparable to the stdlib.h abort() - has no analogue in the JVM, so I was inclined to keep running it through the native interface as before. Best alternate solution is probably to introduce a new ABORT bytecode from the unallocated portion of the JVM bytecodes.

[frankpfenning]

At the moment I would tend to add an ABORT bytecode, rather than going through native. When exactly would the compiler generate that instruction?

On Sun, Dec 16, 2012 at 12:10 PM, Robert J. Simmons < notifications@github.com> wrote:

It's a corner case with the VM - we need to be able to tell the bytecode how to raise SIGABRT. This used to be done via INVOKENATIVE and a call to error(), but the resolution #5https://github.com/frankpfenning/C0/issues/5meant that we couldn't do it that way anymore.

Error behavior - comparable to the stdlib.h exit(1) - is semantically closest to ATHROW. Assertion failure - comparable to the stdlib.h abort()

• has no analogue in the JVM, so I was inclined to keep running it through the native interface as before. Best alternate solution is probably to introduce a new ABORT bytecode from the unallocated portion of the JVM bytecodes.

— Reply to this email directly or view it on GitHubhttps://github.com/frankpfenning/C0/issues/30#issuecomment-11419931.

[robsimmons]

ABORT would be generated whenever we compile the internal language's assert() statement.

• Rob

On Sun, Dec 16, 2012 at 12:17 PM, Frank Pfenning notifications@github.comwrote:

At the moment I would tend to add an ABORT bytecode, rather than going through native. When exactly would the compiler generate that instruction?

On Sun, Dec 16, 2012 at 12:10 PM, Robert J. Simmons < notifications@github.com> wrote:

It's a corner case with the VM - we need to be able to tell the bytecode how to raise SIGABRT. This used to be done via INVOKENATIVE and a call to error(), but the resolution #5< https://github.com/frankpfenning/C0/issues/5>meant that we couldn't do it that way anymore.

Error behavior - comparable to the stdlib.h exit(1) - is semantically closest to ATHROW. Assertion failure - comparable to the stdlib.h abort()

• has no analogue in the JVM, so I was inclined to keep running it through the native interface as before. Best alternate solution is probably to introduce a new ABORT bytecode from the unallocated portion of the JVM bytecodes.

— Reply to this email directly or view it on GitHub< https://github.com/frankpfenning/C0/issues/30#issuecomment-11419931>.

— Reply to this email directly or view it on GitHubhttps://github.com/frankpfenning/C0/issues/30#issuecomment-11420000.

Robert J. Simmons simrob.com rjsimmon@cs.cmu.edu robsimmons@gmail.com Cell: 404-273-6890

[frankpfenning]

But that takes an error string as an argument, which should be printed to stderr and not stdout. I assume the abort we have been talking about does not take these as arguments?

On Sun, Dec 16, 2012 at 12:19 PM, Robert J. Simmons < notifications@github.com> wrote:

ABORT would be generated whenever we compile the internal language's assert() statement.

• Rob

On Sun, Dec 16, 2012 at 12:17 PM, Frank Pfenning notifications@github.comwrote:

At the moment I would tend to add an ABORT bytecode, rather than going through native. When exactly would the compiler generate that instruction?

On Sun, Dec 16, 2012 at 12:10 PM, Robert J. Simmons < notifications@github.com> wrote:

It's a corner case with the VM - we need to be able to tell the bytecode how to raise SIGABRT. This used to be done via INVOKENATIVE and a call to error(), but the resolution #5< https://github.com/frankpfenning/C0/issues/5>meant that we couldn't do it that way anymore.

Error behavior - comparable to the stdlib.h exit(1) - is semantically closest to ATHROW. Assertion failure - comparable to the stdlib.h abort()

• has no analogue in the JVM, so I was inclined to keep running it through the native interface as before. Best alternate solution is probably to introduce a new ABORT bytecode from the unallocated portion of the JVM bytecodes.

— Reply to this email directly or view it on GitHub< https://github.com/frankpfenning/C0/issues/30#issuecomment-11419931>.

— Reply to this email directly or view it on GitHub< https://github.com/frankpfenning/C0/issues/30#issuecomment-11420000>.

Robert J. Simmons simrob.com rjsimmon@cs.cmu.edu robsimmons@gmail.com Cell: 404-273-6890

— Reply to this email directly or view it on GitHubhttps://github.com/frankpfenning/C0/issues/30#issuecomment-11420034.

[robsimmons]

You're right. We could also make an ASSERT bytecode instruction:

S, a, 0 -> print out "a" as a string, call c0_assert_failure or abort(). S, a, i -> S (i != 0)

On Sun, Dec 16, 2012 at 12:21 PM, Frank Pfenning notifications@github.comwrote:

But that takes an error string as an argument, which should be printed to stderr and not stdout. I assume the abort we have been talking about does not take these as arguments?

On Sun, Dec 16, 2012 at 12:19 PM, Robert J. Simmons < notifications@github.com> wrote:

ABORT would be generated whenever we compile the internal language's assert() statement.

• Rob

On Sun, Dec 16, 2012 at 12:17 PM, Frank Pfenning notifications@github.comwrote:

At the moment I would tend to add an ABORT bytecode, rather than going through native. When exactly would the compiler generate that instruction?

On Sun, Dec 16, 2012 at 12:10 PM, Robert J. Simmons < notifications@github.com> wrote:

It's a corner case with the VM - we need to be able to tell the bytecode how to raise SIGABRT. This used to be done via INVOKENATIVE and a call to error(), but the resolution #5< https://github.com/frankpfenning/C0/issues/5>meant that we couldn't do it that way anymore.

Error behavior - comparable to the stdlib.h exit(1) - is semantically closest to ATHROW. Assertion failure - comparable to the stdlib.h abort()

• has no analogue in the JVM, so I was inclined to keep running it through the native interface as before. Best alternate solution is probably to introduce a new ABORT bytecode from the unallocated portion of the JVM bytecodes.

— Reply to this email directly or view it on GitHub< https://github.com/frankpfenning/C0/issues/30#issuecomment-11419931>.

— Reply to this email directly or view it on GitHub< https://github.com/frankpfenning/C0/issues/30#issuecomment-11420000>.

Robert J. Simmons simrob.com rjsimmon@cs.cmu.edu robsimmons@gmail.com Cell: 404-273-6890

— Reply to this email directly or view it on GitHub< https://github.com/frankpfenning/C0/issues/30#issuecomment-11420034>.

— Reply to this email directly or view it on GitHubhttps://github.com/frankpfenning/C0/issues/30#issuecomment-11420063.

Robert J. Simmons simrob.com rjsimmon@cs.cmu.edu robsimmons@gmail.com Cell: 404-273-6890

[robsimmons]

(Temporarily fixed in r187 by changing abort to pabort so that it doesn't conflict with conio.)

[frankpfenning]

Right now there is a function abort(string s) in the standard library document, but in the library itself there appears to be a function pabort.

I think abort (or pabort) is not really necessary. It reintroduces the problem where control-flow analysis won't know that we can't get past the abort. I think we should stick with the new error(s) for and assert(e). We can abort with assert(false), which will give you the error exact location of the assertion failure.

[robsimmons]

Agreed- that's why the issue isn't resolved, I'm on it. You can go ahead and remove pabort if you want, it will only affect the VM. On Dec 24, 2012 8:55 AM, "Frank Pfenning" notifications@github.com wrote:

Right now there is a function abort(string s) in the standard library document, but in the library itself there appears to be a function pabort.

I think abort (or pabort) is not really necessary. It reintroduces the problem where control-flow analysis won't know that we can't get past the abort. I think we should stick with the new error(s) for and assert(e). We can abort with assert(false), which will give you the error exact location of the assertion failure.

— Reply to this email directly or view it on GitHubhttps://github.com/frankpfenning/C0/issues/30#issuecomment-11661057.

[frankpfenning]

I'll leave that to you, Rob, since you have been handling the libraries.

I'll take it out of the documentation.

On Mon, Dec 24, 2012 at 10:25 AM, Robert J. Simmons < notifications@github.com> wrote:

Agreed- that's why the issue isn't resolved, I'm on it. You can go ahead and remove pabort if you want, it will only affect the VM. On Dec 24, 2012 8:55 AM, "Frank Pfenning" notifications@github.com wrote:

Right now there is a function abort(string s) in the standard library document, but in the library itself there appears to be a function pabort.

I think abort (or pabort) is not really necessary. It reintroduces the problem where control-flow analysis won't know that we can't get past the abort. I think we should stick with the new error(s) for and assert(e). We can abort with assert(false), which will give you the error exact location of the assertion failure.

— Reply to this email directly or view it on GitHub< https://github.com/frankpfenning/C0/issues/30#issuecomment-11661057>.

— Reply to this email directly or view it on GitHubhttps://github.com/frankpfenning/C0/issues/30#issuecomment-11662138.

[robsimmons]

ASSERT assed to c0vm in revision 201, and pabort has been removed from both conio.h0 and conio.c0, so this is complete.