On Tue, Jan 14, 2014 at 1:47 AM, Richard Smith <[email protected]>wrote:
> On Mon, Jan 13, 2014 at 8:03 AM, Alp Toker <[email protected]> wrote: > >> >> On 13/01/2014 15:02, Kostya Serebryany wrote: >> >>> Alp, others, >>> >>> Now that there is no urgent issue I'd like to return to the discussion >>> about names with "__" prefix in sanitizer run-times. >>> >> >> If you're OK to conditionalize the code so it's only defined in sanitizer >> builds, that's fine and as Sean pointed out there's already plenty of >> precedent -- it's what every software project does to define "__" prefixed >> weak link functions like libc malloc hooks. >> > > This discussion is so vastly far from the best use of any of our time. > Let's just restore the name we had before and wrap the definition in > __has_feature(leak_sanitizer). I think that will make everyone happy. OK? > There is no __has_feature(leak_sanitizer) and it can't be implemented with reasonable semantics (discussed here before). Unless someone objects, I'll change the code back to use __lsan_is_turned_off and hide it under __has_feature(address_sanitizer), then I will revert my change that added an alternative to __lsan_is_turned_off (LeakSanitizerIsTurnedOffForTheCurrentProcess) This means that -Wreserved, -Wreserved-macros, -Wreserved-identifiers (once implemented) will not work on clang bootstrap in AddressSanitizer mode, but let Alp handle this if it ever becomes a problem. --kcc
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
