Feedback on blog

Thanks for your excellent blog. I am going through and it would be great to submit fixes. Can I do this on github for example? Or how should this be done?

  • JUMPI is exactly the same, but there must not be a “0” in the second position from the top of the stack"
  • (syntax highlighting): move the Transaction slider _all the way to the left and open up the _Instructions section.
  • MSTORE grabs the two last items from the stack (slightly more precise, it pops the two last items from the stack, it doesn't just peeks at them)
  • This basically stores the number 0x80 (decimal 128) into memory at position 0x40 (if looked into Remix into the Memory section I now see 0x80 at the total right at position 0x50, this is a bit confusing. You have to start counting zeros to understand that it wraps around from 0x40 - 0x5f for 32 bytes)
  • ISZERO pushes a 1 to the stack if the topmost value of the stack is zero (this is not what seems to happen, it replaces the topmost value with 1 if it is 0, or in other words, it pops that value and then pushes 1 if the popped value is 0).
  • PUSH2 0010 is unclear, why write 00 if everything is prepended with 00, why is PUSH1 10 not enough? We only have to convey that we want to jump to 16d, when there's no wei involved. Also, to the first reader (me) I first thought it would push two items on the stack, while it's only one of 2 bytes.
  • REVERT will execute with both parameters as 0 (meaning that no useful data will be returned). (This is a bit unclear, what are parameters here? I see that it pushes two times 0 on the stack. Is that what's returned?).
  • try out this simple tool I’ve built: solmap (doesn't seem to work?)
  • JUMPI seems to remove two items from the stack in Remix. The instruction to jump to 0x10, but also the one before that. Weird... Is that a bug in Remix?
  • For example on instruction 18, PUSH1 40, I see Remix updating _initialSupply to 64. Is that another bug in Remix?
  • The first four instructions (17 to 20) read whatever is in memory at position 0x40 and push that to the stack. (This can be rephrased more precisely. What seems to happen is that first 0x40 is pushed to the stack and than the value at that memory position replaces the top of the stack).
  • push 0x0217 (decimal 535) (there's no 0x0217 in the listing in the picture, only 0x0235). (With solidity 0.8.7 it is actually 0x0612 by the way).

And I can go on... but it would only be nice if it's appreciated and when it's moderately easy to suggest changes and they'll be taken up.