Skip to content

Commit cd8e139

Browse files
authored
Fix memory address in self-referential struct example
1 parent 27ac0e1 commit cd8e139

File tree

1 file changed

+2
-2
lines changed
  • blog/content/edition-2/posts/12-async-await

1 file changed

+2
-2
lines changed

blog/content/edition-2/posts/12-async-await/index.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -523,9 +523,9 @@ The internal pointer of our self-referential struct leads to a fundamental probl
523523

524524
The `array` field starts at address 0x10014 and the `element` field at address 0x10020. It points to address 0x1001c because the last array element lives at this address. At this point, everything is still fine. However, an issue occurs when we move this struct to a different memory address:
525525

526-
![array at 0x10024 with fields 1, 2, and 3; element at address 0x10030, still pointing to 0x1001c, even though the last array element now lives at 0x1002a](self-referential-struct-moved.svg)
526+
![array at 0x10024 with fields 1, 2, and 3; element at address 0x10030, still pointing to 0x1001c, even though the last array element now lives at 0x1002c](self-referential-struct-moved.svg)
527527

528-
We moved the struct a bit so that it starts at address `0x10024` now. This could for example happen when we pass the struct as a function argument or assign it to a different stack variable. The problem is that the `element` field still points to address `0x1001c` even though the last `array` element now lives at address `0x1002a`. Thus, the pointer is dangling with the result that undefined behavior occurs on the next `poll` call.
528+
We moved the struct a bit so that it starts at address `0x10024` now. This could for example happen when we pass the struct as a function argument or assign it to a different stack variable. The problem is that the `element` field still points to address `0x1001c` even though the last `array` element now lives at address `0x1002c`. Thus, the pointer is dangling with the result that undefined behavior occurs on the next `poll` call.
529529

530530
#### Possible Solutions
531531

0 commit comments

Comments
 (0)