Konstantin wrote:
> Jakub wrote:
>> I'm strongly against the blacklist,
> I don't like it either. We were forced to implement it by reality.
> ...
> imagine third-party code which you can build but can not change
Same situation here. Reality is that Asan is often thrown at huge (I
mean several MLoc) apps with old, ugly and complicated build systems
(cmake+make+weird bash scripts). Blacklists are by far the easiest
solution in this case (the other being even uglier like writing bash
wrapper around gcc). I agree that ugly codebases aren't GCC's problem
but still.
Jakub wrote:
> I'd prefer not to implement ABI changing options
Agreed.
Konstantin wrote:
>> For others, perhaps, the question is what options to use for them
> Jakub wrote:
> These are asan-internal and not documented anyway.
> Mostly for our own experiments. Don't implement them.
I see. But what about the use-case outlined above (embedded system with
little RAM)? IMHO this is an interesting niche for Asan and friends.
-Y
