Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate asserts for undefined behavior #10

Open
emilaxelsson opened this issue Oct 19, 2012 · 0 comments
Open

Generate asserts for undefined behavior #10

emilaxelsson opened this issue Oct 19, 2012 · 0 comments

Comments

@emilaxelsson
Copy link
Member

Feldspar has a few corners with undefined semantics. These are the ones I can think of:

  • undef and err
  • getIx and setIx
  • setLength can be used to make an array longer, which semantically amounts to appending undefined elements.
  • Size constraints are guarantees provided by the user. If the guarantees are not respected, the result is undefined.

Some undefined programs result in errors in eval, but invalid size annotations will instead result in a bogus value. The C code usually produces a bogus value for undefined programs, but it can probably also crash with a segfault.

It would be nice to have a safe compilation mode where all undefined behavior would be caught by assert/abort in the C code.

Question: Is it an error to use setLength to make an array longer? If yes, this error could easily be caught by an assert. If no, I don't think it's possible to catch errors from indexing uninitialized elements. It would require keeping track of exactly which elements of an array are initialized and which are not. This ultimately requires storing an extra Boolean for each element.

A related problem is when eval has well-defined semantics, but the C code has not. This is the case for e.g. [http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html signed integer overflow]. Should this be caught by an assert as well?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant