Serpent/Solidity function naming mismatch - ABI name contains ()'s

[cseberino]

TL;DR ---- Allow function names with no arguments to have "()" after the name in the ABI

After much grief I figured out why a simple Serpent function that has no params and just
returns a string wouldn't run correctly in Parity.

Here is the ABI Serpent emits...

[{"constant": false, "type": "function", "name": "get_confirmation()", "outputs": [{"type": "bytes", "name": "out"}], "inputs": []}]

I noticed web UI queries on watched contracts keep returning 0x0 (instead of correct return value/string) unless you remove the parens from the function name. In other words, this nonstandard hack is needed for Parity.....

[{"constant": false, "type": "function", "name": "get_confirmation", "outputs": [{"type": "bytes", "name": "out"}], "inputs": []}]

Hope that helps

[jacogr]

Solidity returns the name without any parens. (So there is a mismatch between the Solidty/Serpent outputs here.)

Are you making the calla via the UI when you get the wrong value? (UI definitely doesn't strip the extra ()'s, ABI parsing should be adapted to conform to the difference in inputs)

[cseberino]

Yes I'm doing the call with a "watched contract" via the web UI.

Regardless of whether Serpent or Solidity is following the ABI spec correctly, is it legit
to just make Parity parse out "()" for functions with no args!??

I'm writing a paper on how awesome Parity is for Serpent and I'd like to avoid having
to have a footnote on this if possible if it can be added to repo soon.

[tomusdrw]

According to https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI#json seems that name should contain only function name, not the whole signature, we can parse out \(.*\), but maybe it's worth discussing with Serpent devs too?

name the name of the function (only present for function types);

Web3 is either assuming that it's a signature or constructs the signature:
https://github.com/ethereum/web3.js/blob/develop/lib/utils/utils.js#L191

[jacogr]

Yes, as "specified" it seems to be the name only.

However, I looked at another well-used decoder, they do have the () parse-ignore work-around in-place as well, so it is definitely something that does happen depending on compiler type and version.