specify return-type along "as"

[bitcoinwarrior1]

As discussed in the email regarding bytes and bytesN

Quote Boon:

A) bytes "123456" is encoded as 0x313233343536
B) bytes "12" is encoded as 0x3132
C) bytes1 0x12 is encoded as 0x1200...0 (padded to 32 bytes)
D) bytes2 0x1234 is encoded as 0x123400...0 (trailing 0s so it's padded to 32 bytes)
E) bytes2 0x1200 is encoded as 0x120000...0 (trailing 0s so it's padded to 32 bytes)
F) bytes2 0x0012 is encoded as 0x001200...0 (trailing 0s so it's padded to 32 bytes)

we need to add a return type attribute to function calls so that we do not confuse the apps when interpreting such variables.

Since we are adding this, we can get replace the "as" attribute with return-type and then cast with that.

Since July schema added in bytes, we ought to add this and then skip July in lieu of a later month.

[SmartLayer]

This is what I propose.

For variable bytes return types

<ts:attribute-type id="foobytesa" syntax="1.3.6.1.4.1.1466.115.121.1.27">
  <ts:origins>
    <ts:ethereum as="bytes" contract="FooToken" function="return_bytes">
      <ts:data/>
    </ts:ethereum>
  </ts:origins>
</ts:attribute-type>

For fixed bytesN return types

Example: bytes2 - refer to Boon's E)

<ts:attribute-type id="foobytesa2" syntax="1.3.6.1.4.1.1466.115.121.1.27">
  <ts:origins>
    <ts:ethereum as="bytes" contract="FooToken" function="return_bytes2" 
      bitmask="FFFF000000000000000000000000000000000000000000000000000000000000">
      <ts:data/>
    </ts:ethereum>
  </ts:origins>
</ts:attribute-type>

So let's say return_bytes2 returns this:

0x1200000000000000000000000000000000000000000000000000000000000000

And according to the bitmask, then internally it is first trimmed to

0x1200

Example: bytes1 - refer to Boon's C)

<ts:attribute-type id="foobytesa1" syntax="1.3.6.1.4.1.1466.115.121.1.27">
  <ts:origins>
    <ts:ethereum as="bytes" contract="FooToken" function="return_bytes1"
      bitmask="FF000000000000000000000000000000000000000000000000000000000000">
      <ts:data/>
    </ts:ethereum>
  </ts:origins>
</ts:attribute-type>

So let's say return_bytes1 returns this:

0x1200000000000000000000000000000000000000000000000000000000000000

And according to the bitmask, then internally it is trimmed to

0x12

---

Extensions

<ts:ethereum as="bytes" contract="FooToken" function="return_bytes2" bitmask="00FF…">

Where … represents any number of FFs to match the data returned. In the example, the first byte is discarded from data of any length.

[SmartLayer]

Implicit conversion

• if the attribute type is an Integer, and the origin is returned with as="utf8", then there is an implicit conversion whose rules are not defined anywhere in the TokenScript file.
• Similarly, if the original is returned with as="bytes", how that is converted to an Integer is implicitly big-endian, but what if the smart contract author intended to use two's complement?

[hboon]

We might have cases like this that has a defacto conversion path (can't think of any at the moment. Brain is slow) already.

But the examples for implicit conversion above aren't so clear-cut, so we can either decide how to convert for each case, preferably with a rule or two to govern the decision for consistency, or we can label it as undefined behavior and shove it under the carpet like the creators of C and C++ did..

[bitcoinwarrior1]

Solved with 2019/10