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 use of plain field names with jvm_field_is #902

Closed
brianhuffman opened this issue Nov 14, 2020 · 0 comments · Fixed by #922
Closed

Allow use of plain field names with jvm_field_is #902

brianhuffman opened this issue Nov 14, 2020 · 0 comments · Fixed by #922
Assignees
Labels
subsystem: crucible-jvm Issues related to Java verification with crucible-jvm

Comments

@brianhuffman
Copy link
Contributor

Currently when writing jvm specs, jvm_field_is declarations must be used with a fully-qualified field name that includes the class name. Here's an example setup block from ecdsa-crucible.saw:

  do {
    this <- jvm_alloc_object "com.galois.ecc.P384ECC64";
    ph <- jvm_alloc_array 12 java_int;
    jvm_field_is this "com/galois/ecc/ECCProvider.h" ph;
    ...

In order to determine the right fully-qualified name for field h, the user has to basically perform a full field resolution procedure: No field h is declared in class P384ECC64, so check the superclass NIST64. There's no field h in NIST64 either, so check its superclass ECCProvider. Finally, we find that ECCProvider does declare a field h, so that's the qualified name we use.

Instead of making the user do this, saw should do it automatically. The user should be able to write jvm_field_is this "h" ph. Then saw should look up the class of the this reference, and resolve the field name h by checking the superclasses in order until a match is found.

Even so, we probably want to continue to allow users to optionally specify fully-qualified field names that include a classname. This is occasionally necessary in the case where a subclass declares a field that shadows a similarly-named field in a superclass; in such cases the unqualified name would always default to the field of the subclass.

@brianhuffman brianhuffman added the subsystem: crucible-jvm Issues related to Java verification with crucible-jvm label Nov 14, 2020
@brianhuffman brianhuffman self-assigned this Nov 14, 2020
brianhuffman pushed a commit that referenced this issue Nov 18, 2020
It now performs field resolution on the base field name to determine
the complete fieldId including class name and type.

This implements part of the feature requested in #902.

However, as it stands the feature is not backward-compatible, as
*only* unqualified names currently work. The field resolution
procedure needs to be updated to allow optional qualified names.
brianhuffman pushed a commit that referenced this issue Nov 18, 2020
It now performs field resolution on the base field name to determine
the complete fieldId including class name and type.

This implements part of the feature requested in #902.

However, as it stands the feature is not backward-compatible, as
*only* unqualified names currently work. The field resolution
procedure needs to be updated to allow optional qualified names.
brianhuffman pushed a commit that referenced this issue Nov 18, 2020
It now performs field resolution on the base field name to determine
the complete fieldId including class name and type.

This implements part of the feature requested in #902.

However, as it stands the feature is not backward-compatible, as
*only* unqualified names currently work. The field resolution
procedure needs to be updated to allow optional qualified names.
brianhuffman pushed a commit that referenced this issue Nov 18, 2020
It now performs field resolution on the base field name to determine
the complete fieldId including class name and type.

This implements part of the feature requested in #902.

However, as it stands the feature is not backward-compatible, as
*only* unqualified names currently work. The field resolution
procedure needs to be updated to allow optional qualified names.
brianhuffman pushed a commit that referenced this issue Nov 18, 2020
It now performs field resolution on the base field name to determine
the complete fieldId including class name and type.

This implements part of the feature requested in #902.

However, as it stands the feature is not backward-compatible, as
*only* unqualified names currently work. The field resolution
procedure needs to be updated to allow optional qualified names.
brianhuffman pushed a commit that referenced this issue Nov 18, 2020
It now performs field resolution on the base field name to determine
the complete fieldId including class name and type.

This implements part of the feature requested in #902.

However, as it stands the feature is not backward-compatible, as
*only* unqualified names currently work. The field resolution
procedure needs to be updated to allow optional qualified names.
brianhuffman pushed a commit that referenced this issue Nov 19, 2020
It now performs field resolution on the base field name to determine
the complete fieldId including class name and type.

This implements part of the feature requested in #902.

However, as it stands the feature is not backward-compatible, as
*only* unqualified names currently work. The field resolution
procedure needs to be updated to allow optional qualified names.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
subsystem: crucible-jvm Issues related to Java verification with crucible-jvm
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant