Use string type or bytes32?
stringfor arbitrary-length string (UTF-8) data that's longer than 32 bytes. Frontends can decode a long string easier using methods like web3.toAscii or UTF-8 (when issues are fixed), instead of implementing the logic of UTF-8 decoding a series of
From Solidity docs:
As a rule of thumb, use
bytesfor arbitrary-length raw byte data and
stringfor arbitrary-length string (UTF-8) data. If you can limit the length to a certain number of bytes, always use one of
bytes32because they are much cheaper.
String literals may also be helpful or convenient:
String literals are written with either double or single-quotes ("foo" or 'bar')...
String literals support escape characters, such as \n, \xNN and \uNNNN. \xNN takes a hex value and inserts the appropriate byte, while \uNNNN takes a Unicode codepoint and inserts an UTF-8 sequence.
bytes32uses less gas because it fits in a single word of the EVM, and
stringis a dynamically sized-type which has current limitations in Solidity (such as can't be returned from a function to a contract).
I am not sure if I understood the last sentence - string return types work in current Solidity compiler.
@MikkoOhtamaa Emphasis is *to a contract*: I don't think http://ethereum.stackexchange.com/a/3788/42 is supported yet.
Ok so if you have a controlling contract and it's accessing data from another contract which is returning text that is longer than 32 bytes, you would need to return it in a bytes32 array?
@ethereal Sounds right, give a size to the array like bytes32. There may be assembly ways to get the size of the data being returned and avoiding a hardcoded size, for example the contracts in https://github.com/ownage-ltd/ether-router