Skip to content

Remove wrong assumption on opaque methods #2857

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Aug 30, 2018
Merged

Remove wrong assumption on opaque methods #2857

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 6 additions & 11 deletions jbmc/src/java_bytecode/java_bytecode_convert_method.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2189,18 +2189,13 @@ void java_bytecode_convert_methodt::convert_invoke(
// inherit a definition from a super-class, we create a new symbol and
// insert it in the symbol table. The name and type of the method are
// derived from the information we have in the call.
// We fix the access attribute to ID_public, because of the following
// We fix the access attribute to ID_private, because of the following
// reasons:
// - We don't know the orignal access attribute and since the .class file
// - We don't know the original access attribute and since the .class file is
// unavailable, we have no way to know.
// - Whatever it was, we assume that the bytecode we are translating
// compiles correctly, so such a method has to be accessible from this
// method.
// - We will never generate code that calls that method unless we
// translate bytecode that calls that method. As a result we will never
// generate code that may wrongly assume that such a method is
// accessible if we assume that its access attribute is "more
// accessible" than it actually is.
// - The translated method could be an inherited protected method, hence
// accessible from the original caller, but not from the generated test.
// Therefore we must assume that the method is not accessible.
irep_idt id = arg0.get(ID_identifier);
if(
symbol_table.symbols.find(id) == symbol_table.symbols.end() &&
Expand All @@ -2213,7 +2208,7 @@ void java_bytecode_convert_methodt::convert_invoke(
symbol.pretty_name = id2string(arg0.get(ID_C_class)).substr(6) + "." +
id2string(symbol.base_name) + "()";
symbol.type = arg0.type();
symbol.type.set(ID_access, ID_public);
symbol.type.set(ID_access, ID_private);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the above argument - can we assume it is in fact protected?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not guaranteed. It can well be private. The previous assumption (ID_public) was based on the fact that we wouldn't call these functions in generated tests. But I don't think we can completely exclude finding calls to private methods in generated tests, e.g. when mocking private methods (if we do partial mocking in the future), so we need to know consider that the method can be private. Anyway it's too early to make assumptions on how we'll be calling these methods, so we need to stay accurate.
Should I make the comment clearer?

symbol.value.make_nil();
symbol.mode = ID_java;
assign_parameter_names(
Expand Down