akegaviar / ton-foo

MIT License
0 stars 0 forks source link

Inconsistent slice when calling my_address() in different contexts #498

Open akegaviar opened 4 months ago

akegaviar commented 4 months ago

I am encountering an inconsistency when calling my_address() in different contexts and hope someone can help me understand why this is happening.

When I call my_address() within get function, it returns a slice that starts with 0 bits, as shown below:

CS{Cell{004380008d090b360188f0560ee4010388f181ad345579022d85d84b0ac904ead5acb410} bits: 0..267; refs: 0..0}

Conversely, when I call my_address() within an impure function, it returns a slice that starts with 1 bit:

CS{Cell{026fc0004684859b00c4782b07720081c478c0d69a2abc8116c2ec25856482756ad65a0254910843292a22680000000001ab3f0500bd26da1340} bits: 1..268; refs: 0..0}

Despite these differences, when I parse both addresses with parse_std_addr, they return the same workchain and 256-bit integer address:

workchain = 0
integer address = 1993502832782254581058910437300945815969310326214648768594806511355848123808

Therefore, when calculating a child contract address using my_address, it yields different results depending on the context in which it's called. Can anyone explain why this is happening and how I should handle it?

Answer

The CS{Cell{...} bits: 0..267; refs: 0..0} is the string representation of a slice. A slice is a structure for reading a cell.

In your example, depending on the context, 2 different cells where returned and converted to slices. The first one has 267 bits, and the second has 268 bits, but also starts from bit 1.

That is, even though these cells are different, because slices are starting at different indexes, they represent the same thing at the end, and as you said, after parsing them using parse_std_addr, they both return the same address.

Using this address, they must produce the same child address. You're problem might lie in that part of your code.


Original