@MaskRay many thanks for your helpful comments on our first PR - that’s much appreciated.
The meaning of “RAD” was, in truth, originally only a placeholder. We found it difficult to choose a suitable abbreviation for “Realtime”, and considered options like rsan and rtsan. At the time of development, we discounted rsan because it sounds like a mildly rude word in British English, and we (perhaps short-sightedly) discounted rtsan because we didn’t want it to clash with the “rt” in compiler-rt. We just left it as “RADSan” and agreed to find a “backronym” later (“real-time application development”? “real-time and deterministic”?).
Now is, of course, the time to choose. We agree that radsan doesn’t align well with the existing convention above. Had it not been for the rt clash with compiler-rt, our ideal abbreviation was also rtsan. If rtsan is acceptable to the LLVM team, we would be very happy to rename radsan to rtsan.
Would the LLVM team be happy for us to go with rtsan?
I’m not very familiar with TCB enforcement, so I can’t yet comment on this. But if RealtimeSanitizer were a specialised case of what you describe (i.e. defined by a pre-determined set of library functions), do you think it would be acceptable for -fsanitize=realtime to continue to exist as a thin wrapper around a more abstract TCB sanitizer, like you envisage?