Skip to content
This repository has been archived by the owner on Nov 15, 2021. It is now read-only.

string arguments in load_run are sometimes parsed incorrectly #412

Closed
fyrchik opened this issue May 10, 2018 · 4 comments
Closed

string arguments in load_run are sometimes parsed incorrectly #412

fyrchik opened this issue May 10, 2018 · 4 comments

Comments

@fyrchik
Copy link
Contributor

fyrchik commented May 10, 2018

Current behavior

I have experienced a very STRANGE bug. I want to provide a string argument to smart-contract, However sometimes I get an error (even BEFORE execution starts, so the problem is in neo-python shell):
Could not load script argument should be bytes, buffer or ASCII string, not 'float'

Strings, that caused this error: "ny", "anf", "puhnaty"
Strings, that didnt cause error: "kn", "antz" ...

See the pattern?
Exactly! If we cast strings to byte array and then to hex, strings in first line will contain only numbers and 'e', so they can be interpreted as float (!)
Seems, like it is happening in neo/Prompt/Utils.py:parse_param, where eval takes as argument hex representation of string, however I had not found a quick way to fix it.

Expected behavior

All strings are processed correctly.

How to reproduce

Probably any load_run *.avm where one of arguments is string.

Your environment

Let us know in what environment you're running into the issue:

Linux dzeta-pc 4.13.0-41-generic #46-Ubuntu SMP Wed May 2 13:38:30 UTC 2018 x86_64 GNU/Linux
neo-python v0.7.0-dev
Python 3.6.3

@localhuman
Copy link
Collaborator

Thanks for submitting the issue!

For me, this only happens when using these strings in a list in the arguments. So the following works: testinvoke {hash} ny [] whereas this does not: testinvoke {hash} mystr ['ny']

@localhuman
Copy link
Collaborator

localhuman commented May 10, 2018

I've been able to fix this issue by commenting out the following line:
https://github.com/CityOfZion/neo-python/blob/master/neo/Prompt/Utils.py#L185

If you're interested in making a PR for the fix that would be great! Otherwise we can get it done. Will need to add some more tests to catch cases like these 😆

@fyrchik
Copy link
Contributor Author

fyrchik commented May 11, 2018

@localhuman yes, removing return indeed fixes all of my problems 😀. I had created a PR.

@dethos
Copy link
Contributor

dethos commented Jun 5, 2018

If this issue is solved, perhaps would be better to close it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants