The macros defined in sanitizer/asan_interface.h and in our header are the
same. For consistency I just re-defined them. When the header is available,
since it looks like the macros have been there for a long time, we can just
skip redefining it and use them directly. I'll add a comment.

On Tue, Jan 10, 2023 at 9:09 AM Ioi Lam <ik...@openjdk.org> wrote:

> On Mon, 9 Jan 2023 15:48:48 GMT, Justin King <jck...@openjdk.org> wrote:
>
> >> I like this, but would compilers not complain about unused statements?
> >
> > I don't believe so, at least not based on current options. Other
> projects use similar tricks, like ABSL_DCHECK from Abseil which short
> circuits expressions when in non-debug builds causing the code to be
> unreachable and stripped. If it does, we can always just remove the if
> statement part and have it evaluate anyway. Most compilers should realize
> that the statements are unused and should be pruned.
>
> The macros `ASAN_POISON_MEMORY_REGION` and `ASAN_UNPOISON_MEMORY_REGION`
> are already defined in [sanitizer/asan_interface.h](
> https://opensource.apple.com/source/clang/clang-700.1.81/src/projects/compiler-rt/include/sanitizer/asan_interface.h.auto.html),
> but we redefine them here.
>
> Since ASan is going to be an obscured feature for many HotSpot developers,
> I don't think we should make it more obscured.
>
> I think it's better to declare our own macros that call into the existing
> macros. Maybe something like
> `_ASAN_POISON_MEMORY_REGION`. The comments should be improved to say why
> we do this (to prevent people that don't use ASan from breaking ASan).
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/11702
>


-- 

[image: Google Logo]
Justin King
Software Engineer
jck...@google.com

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to