You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Error Accessing Internal Pointer Objects Across Different Files in Imported Package
Description
An error occurs while deploying the GRC721 package using the grc721.NewNFTWithMetadata(name string, symbol string) function.
When attempting to deploy the package, an access denied message appears alongside an error indicating issues with accessing internal pointer objects.
This problem seems to arise when importing the package and attempting to access pointer objects from different files within the imported package.
Observe the Access Error:
An error message indicating inability to access internal pointer objects appears during deployment.
Expected behaviour
The GRC721 package should deploy successfully without any access-related errors, allowing seamless interaction with internal objects and pointer references within the package.
Actual behaviour
During the deployment process, an access error occurs, preventing the use of the metadataNFT within the meta_nft package. This error suggests that the package cannot access certain internal pointer objects after being imported.
It might be beneficial to modify the FindEmbeddedFieldType function within gnovm to ensure that the callerPath accurately reflects the immediate caller’s package path rather than defaulting to the top-level package path.
Currently, during recursive function calls, callerPath is maintained as the top-level package path, which seems to cause a loss of context regarding the immediate caller’s package.
callerPath is the path to the calling package's path when executing the recursive function.
Rationale:
By updating the callerPath to the immediate caller’s package path, the function can correctly identify package boundaries and enforce access permissions accurately.
In this condition of the FindEmbeddedFieldType function, you can check if they are called from the same package. [Check Pacakge Path] (
This change will prevent the access errors encountered during the deployment of the GRC721 package.
Additional Information
The existing implementation of the FindEmbeddedFieldType function passes the callerPath as the top-level package path during recursive calls.
This approach appears to cause the function to lose the context of the immediate caller’s package path, leading to incorrect access permissions and preventing interaction with internal pointer objects.
Error Accessing Internal Pointer Objects Across Different Files in Imported Package
Description
An error occurs while deploying the GRC721 package using the
grc721.NewNFTWithMetadata(name string, symbol string)
function.When attempting to deploy the package, an access denied message appears alongside an error indicating issues with accessing internal pointer objects.
This problem seems to arise when importing the package and attempting to access pointer objects from different files within the imported package.
Your environment
Steps to reproduce
gno.land/p/demo/grc/grc721
package.grc721.NewNFTWithMetadata(name string, symbol string)
function.An error message indicating inability to access internal pointer objects appears during deployment.
Expected behaviour
The GRC721 package should deploy successfully without any access-related errors, allowing seamless interaction with internal objects and pointer references within the package.
Actual behaviour
During the deployment process, an access error occurs, preventing the use of the metadataNFT within the meta_nft package. This error suggests that the package cannot access certain internal pointer objects after being imported.
Logs
Proposed solution
It might be beneficial to modify the
FindEmbeddedFieldType
function within gnovm to ensure that the callerPath accurately reflects the immediate caller’s package path rather than defaulting to the top-level package path.Currently, during recursive function calls, callerPath is maintained as the top-level package path, which seems to cause a loss of context regarding the immediate caller’s package.
callerPath is the path to the calling package's path when executing the recursive function.
Rationale:
By updating the callerPath to the immediate caller’s package path, the function can correctly identify package boundaries and enforce access permissions accurately.
In this condition of the
FindEmbeddedFieldType
function, you can check if they are called from the same package. [Check Pacakge Path] (gno/gnovm/pkg/gnolang/types.go
Lines 1626 to 1628 in 4f27a57
This change will prevent the access errors encountered during the deployment of the GRC721 package.
Additional Information
The existing implementation of the
FindEmbeddedFieldType
function passes the callerPath as the top-level package path during recursive calls.This approach appears to cause the function to lose the context of the immediate caller’s package path, leading to incorrect access permissions and preventing interaction with internal pointer objects.
Relevant Links:
The text was updated successfully, but these errors were encountered: