steakhal wrote: > [...] I'm a bit confused by the first commit because as far as I see, the > empty struct is _unable to_ transfer any attacker-controlled data, and > therefore I don't know what does it mean that it's tainted.
Exactly. Because we don't let the bind operations go through, the copies won't have an identity, thus there is nothing where taint could bind to. However, it only looking at the code users could get confused (rightly so). For example, when the *dedicated* users reduce their reproducers, they would find it surprising to suddenly break taint propagation in their example when they remove the last remaining member of the class that was supposed to carry taint. They may overlook that they broke their reproducer and draw false conclusions of the issue. >[...] Do you have a practical use case where this would be useful? I'd say, not really. Another way of looking at that is remaining consistent no matter how many fields we have in a class. And btw, given that all objects must be at least of one byte, actually, even an empty class has 1 byte of semi-usable storage. If that empty class is tainted, then reinterpret-casting it to a single char should be also considered tainted. But again, I don't really expect this to happen in practice, and we can drop that commit from the stack without affecting the outcome of fixing the issue motivating this stack. However, I'd lean towards a more consistent behavior for structs, no matter their guts. https://github.com/llvm/llvm-project/pull/114835 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
