Replies: 2 comments
-
We should not allow the interpreter to modify, but also read, the unexported variables of an Used package. This hole exists because unexported values are simply ignored when building the wrappers to pre-compiled packages using |
Beta Was this translation helpful? Give feedback.
-
It occurs to me that it doesn't matter all that much. You can just capitalize the given variable name (it's just a string, after all) and it wouldn't matter. So even if it is a bug, and even if you fix it, it's trivial to circumvent. 🤷🏻♂️ Thanks for the quick answer, though. |
Beta Was this translation helpful? Give feedback.
-
This test case defines an unexported variable, imports it into the interpreter, and can successfully query it and assign to it.
That's handy for my current use-case but nevertheless seems at least questionable. (To wit, I'm questioning it. :)
If this is not intended behavior, happy to file a bug.
Discussion: If the code calling
i.Use
can access the variable to get its address in the first place, then it does actually seem reasonable for the interpreter to be able to access the variable, so it's not like the interpreter is actually breaking any fundamental rules. It seems like whether it's intended behavior or not, there should be a test case for it, and perhaps a note in the interp.Use documentation.Beta Was this translation helpful? Give feedback.
All reactions