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

Allow reading and writing structured objects in Java analysis #158

Closed
atomb opened this issue Jul 7, 2016 · 3 comments
Closed

Allow reading and writing structured objects in Java analysis #158

atomb opened this issue Jul 7, 2016 · 3 comments
Labels
obsolete Issues that involve/depend on deprecated code, such that they are not worth pursuing subsystem: crucible-jvm Issues related to Java verification with crucible-jvm type: enhancement Issues describing an improvement to an existing feature or capability wontfix Closed issues that we decided not to fix, but are still potentially relevant

Comments

@atomb
Copy link
Contributor

atomb commented Jul 7, 2016

Right now, arrays of scalars can be read and written from the Java heap as monolithic entities. Similarly, it would be possible in principle to specify or extract the value of an object as a SAWCore record, but that's not currently implemented.

@atomb atomb added the type: enhancement Issues describing an improvement to an existing feature or capability label May 2, 2017
@atomb atomb added this to the 1.0 milestone Jun 4, 2019
@atomb atomb modified the milestones: 0.5, 0.6 Mar 31, 2020
@atomb atomb modified the milestones: 0.6, 0.7 Aug 6, 2020
@brianhuffman brianhuffman added subsystem: crucible-jvm Issues related to Java verification with crucible-jvm obsolete Issues that involve/depend on deprecated code, such that they are not worth pursuing and removed subsystem: crucible-jvm Issues related to Java verification with crucible-jvm labels Oct 16, 2020
@brianhuffman
Copy link
Contributor

The old Java stuff is obsolete, but we should make sure that the new crucible/jvm stuff supports the same feature.

@brianhuffman
Copy link
Contributor

For crucible/jvm, issue #422 is specifically about reading and writing arrays. We'll have to think about whether it makes sense to read and write objects with named fields.

@atomb atomb removed this from the 0.7 milestone Oct 16, 2020
@brianhuffman brianhuffman added the wontfix Closed issues that we decided not to fix, but are still potentially relevant label Dec 4, 2020
@brianhuffman
Copy link
Contributor

One of the tricky things about mapping between JVM object field names and Cryptol record fields is that JVM field names are not just identified by name; the class name and type are also used to identify a field of an object. The class name of a field might be the class of the object, or else it could be a superclass. It's not obvious how users would typically want those fields to be organized. Should they be one flat record? But that doesn't work if some field names shadow the names from a superclass. We could have a record field called super that contains the fields from the immediate superclass (and then that record could contain another super field containing a record of fields from its superclass, and so on). But while that would work in general, it's a bit complicated and arbitrary, and might not match the way people would want to write their cryptol specs.

Basically, I'm thinking that this is not something we want to implement. The saw-script commands, as they exist now, let you define your own object-specific wrapper functions for the JVMSetup monad that let you specify objects with lots of fields at once, and you can combine the fields in whatever Cryptol expression you want, using tuples, records, sequences, or whatever matches the style of Cryptol spec you have. A hard-coded points-to declaration for entire objects at once will be much less flexible, and probably not nearly as useful. So I'm going to close this ticket as "won't fix", if that's ok with everyone else.

brianhuffman pushed a commit that referenced this issue Apr 26, 2021
Update to follow changes in What4
brianhuffman pushed a commit that referenced this issue Apr 26, 2021
This adapts cryptol-saw-core to GaloisInc/cryptol#1066.

(Note: saw-core PR #158 was intended to adapt to the same cryptol
PR, but missing translations for the new cryptol primitives caused
the cryptol-saw-core test suite to fail. This PR fixes the test
suite failure.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
obsolete Issues that involve/depend on deprecated code, such that they are not worth pursuing subsystem: crucible-jvm Issues related to Java verification with crucible-jvm type: enhancement Issues describing an improvement to an existing feature or capability wontfix Closed issues that we decided not to fix, but are still potentially relevant
Projects
None yet
Development

No branches or pull requests

2 participants