Re: Bug report for assignment inside methods

[Mohammad-Reza Nabipoor]

On Mon, May 22, 2023 at 09:08:28PM +0200, Mohammad-Reza Nabipoor wrote:
> 
> Bug:
> 
> (poke) .mem
> (poke) byte[] @ 0x10#B = [0x83UB, 0xfUB]
> (poke) type Byte = struct uint<8> { uint<1> hi : hi == 1; uint<7> lo; }
> (poke) type Num = struct { Byte[] variable; uint<8> last; method set = 
> (Byte[] v, uint<8> l) void: { variable = v; last = l; } }
> (poke) var n = Num @ 0x10#B
> (poke) n
> Num {
>   variable=[Byte {
>     hi=(uint<1>) 0x1,
>     lo=(uint<7>) 0x03
>   }],
>   last=0x0fUB
> }
> (poke) n.set (Byte[] (), 0)
> (poke) dump
> 76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF
> 00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
> 00000010: 8300 0000 0000 0000 0000 0000 0000 0000  ................
> 
> 
> So, what happens is that in `set' method, on assignments, we call `SSET'
> instruction (which in turn calls `pvm_set_struct' function).
> When we change the `variable' from an array of size 1 to an array of
> size 0, it should fix the boffset of next field (`last') to `0x10#B'.
> That's not the case in the current implementation, and the boffset of `last'
> stays as `0x11#B'.
> 
> Then after `SSET', we call `WRITE' instruction, which will write the empty
> array at offset `0x10#B` (which is a NOP) and writes the `last' (which has
> value 0) to offset `0x11#B' (which is wrong).
> So, you see that `byte @ 0x11#B' has been changed from `0x0fUB' to `0UB'.
> 
> So the question is how should I fix the the boffset of values in a struct?
> In `pvm_set_struct'?
> Or we should add new instruction? Or ...?


I think we correct thing to do is to run the constructor (after `SSET') for
mapped values, but the problem is when we're in the body of methods, the
constructor is not synthesized yet.

Time for lexical revamp?