The patch looks good to me. For now, IMO we should wait a few days for the discussion on sdcc-devel on LLM use to settle.
The patch looks good to me (except for the naming of the parameters - I'd prefer "target" instead of "new", "source" instead of "orig" to keep the terminology consistent, but I can change that when applying). For now, IMO we should wait a few days for the discussion on sdcc-devel on LLM use to settle.
The approach would work, but it doesn't feel elegant to me. Treating pointer arithmetic on _Optional differently for so long feels (i.e. from AST to the early stages of processing the iCode) inelegant. Maybe we should keep all these +0 in AST, and eliminate them later? But that might have a code quality penalty (but if that is the case, we'd already see a code quality regression for adding zero to pointers to _Optional with this patch).
The test passes for me, even with current SDCC.
The patch looks good to me. When I apply it, I'll also add a test in support/valdiag. For now, IMO we should wait a few days for the discussion on sdcc-devel on LLM use to settle.
The changes to SDCC itself look good to me. But I'm not a Python programmer, so I'd like to get the opinion of someone who knows Python (used for the test) before the patch goes in.
The copy of *object to *expected is not required to be atomic, only the read of *object is atomic, the write to *expected does not need to be. Only *object is an atomic type, *expected isn't. So I think our current implementation should be good enough.
The copy of *object to *expected is not required to be atomic, only the read of *object is atomic, the write to *expected does not need to be. Only *object is an atomic type, *expected isn't.