Project Coin: Inducing contributory heap pollution

Neal Gafter neal at
Thu Jun 10 10:51:15 PDT 2010

On Thu, Jun 10, 2010 at 10:15 AM, Joe Darcy <joe.darcy at> wrote:
>  Inheriting the diagnostic-suppression annotation would be a great way
>> to induce contributory heap pollution.  All you have to do is extend a
>> class with a warning-suppressed varargs method, providing an unsafe
>> overriding implementation, and voila!  Heap pollution without a
>> warning.
> I was thinking that the spec for the annotation would allow compilers to
> issue errors if they could prove bad things actually happen in an
> implementation of a so annotated method.

That's conservative in the wrong direction.  Allowing errors [sic; warnings]
isn't good enough.  You have to require them when there's any possibility of
heap pollution.  In other words, you'd have to require the diagnostic unless
the compiler can prove that bad things won't happen.  For code portability,
you'd have to specify what "the compiler can prove" means, precisely.  And
if we could do that, then we wouldn't need any of these annotations in the
first place.

"If I could walk that way I would not need talcum powder!"


More information about the coin-dev mailing list