`*&foo=bar` pattern appears to result in false positives under hwasan

[tamird]

Hello!

We're seeing hwasan crashes here:

opusfile/src/opusfile.c

Lines 1448 to 1449 in d2535e6

	*&oy_start=_of->oy;
	*&os_start=_of->os;

Abort message: '==app_process64==3243==ERROR: HWAddressSanitizer: tag-mismatch on address 0x007700154c38 at pc 0x0077a2995bcc
WRITE of size 408 at 0x007700154c38 tags: 00/75 (ptr/mem) in thread T51
Invalid access starting at offset 264
#0 0x77a2995bcc  (/apex/com.android.runtime/lib64/bionic/libclang_rt.hwasan-aarch64-android.so+0x25bcc) (BuildId: 558b5c131872716737ddc0a62f3382dd3df70b9a) push_back [out/lib/compiler-rt-aarch64/out/llvm-project/compiler-rt/lib/lsan/../sanitizer_common/sanitizer_common.h:519 + 0x0]
#1 0x771178c014  (/mylib.so+0x40aa014) (BuildId: 8a73353f0af2d118391f2338360e31e0ad79675c) (inlined) op_open_seekable2 [./myproject/third-party/opusfile/opusfile/src/opusfile.c:1442 + 0xc]
op_open2 [./myproject/third-party/opusfile/opusfile/src/opusfile.c:1588 + 0xc]
#2 0x771178bee4  (/mylib.so+0x40a9ee4) (BuildId: 8a73353f0af2d118391f2338360e31e0ad79675c) op_open_callbacks [./myproject/third-party/opusfile/opusfile/src/opusfile.c:1631 + 0x0]

our suspicion is that the crash is caused by a tag mismatch from HWASan when writing to a stack variable (oy_start) via a raw pointer assignment:

*&oy_start = _of->oy;

While functionally equivalent to oy_start = _of->oy; in standard C, this form bypasses HWASan’s stack instrumentation. The pointer used for the write does not carry the correct HWASan memory tag, resulting in a mismatch (e.g., tags: 00/75). Replacing it with a direct assignment resolves the issue and preserves HWASan safety.

There are a few more instances of this pattern in the codebase, which should all be changed, I think.

[tamird]

@rillian any thoughts on this or the proposed fix in #58?

[rillian]

Thanks for the patch. FWIW, this is what the original author said about the idiom:

This is an anachronistic idiom meant to satisfy pre-c89 compilers that supported struct assignment, but only through pointers and not in the direct syntax standardized in ANSI C. It is probably unnecessary in 2025, although I liked the visual reminder that we are not operating on a primitive type. It is pretty strange that Android's ASAN barfs on it, since as far as I can tell it is completely valid C.

[tamird]

Thanks for the context! I agree that something suspicious is going on with hwasan, we're still investigating what looks like incorrect codegen in some cases (though I don't know if that's what's happening here). Either way, seems better to avoid the anachronism.