问题标签 [heap-pollution]

我们使用了一些可变参数函数，当我们迁移到 java 1.7 时，我们会收到一个奇怪的未经检查的警告。

接口ICache中的函数添加

在一个界面报告错误。

O 扩展了 Object，作为它的通用缓存类。

我阅读了 xlint 警告，我们在未选中的情况下进行编译，但http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#xlintwarnings似乎暗示这个错误应该是[varargs] 类型不是未经检查的类型。

我错过了什么吗？

我有一个像下面这样的构造函数

Eclipse 用以下消息警告我：

类型安全：通过可变参数对象的潜在堆污染

我像这样更改构造函数：

现在，警告消失了。但是，我认为潜在的危险并没有解决。

这种解决方法有效吗？

我正在阅读有关varargs 堆污染的内容，但我并没有真正了解 varargs 或不可具体化的类型将如何对没有通用性的情况下不存在的问题负责。确实，我可以很容易地替换

和

第二个简单地使用了数组的协方差，这确实是这里的问题。（即使List<String>是可具体化的，我想它仍然是的子类，Object我仍然可以将任何对象分配给数组。）当然我可以看到两者之间有一点区别，但是这段代码是否有问题是否使用泛型。

他们所说的堆污染是什么意思（这让我想到了内存使用，但他们谈论的唯一问题是潜在的类型不安全），它与使用数组协方差的任何类型违规有何不同？

我在 Java 的 CERT 安全编码标准中遇到了这条规则。堆污染。我知道这可能会导致程序在运行时抛出异常，但我不明白这会如何导致像 dos 之类的安全问题。有人可以解释攻击者可以利用堆污染的场景吗？

我有一个功能。我喜欢我的功能。它列出了清单，这让我很开心。我的 IDE 给了我一个关于我的函数的警告，谈论潜在的堆污染。我可以添加一个注释来抑制这个警告，但我想确保我没有抑制一个合法的问题。谁能确认以下功能是否安全/不安全？

我正在尝试决定每次在使用参数化可变参数时收到 Java 堆污染警告时该怎么做，例如

在我看来，如果我有信心不在我的方法中使用一些奇怪的演员表，我应该使用@SafeVarargs并继续前进。但这是正确的，还是我需要更加小心？使用参数化可变参数时，是否有明显正确的代码实际上不安全？

阅读有关该主题的内容后，我注意到提供的示例非常人为。例如，Java 文档显示了以下错误方法：

这是说教的，但很不切实际；有经验的程序员不太可能编写这样的代码。另一个例子是

这显然是以不切实际的方式混合类型。

那么，在参数化可变参数下是否存在更微妙的堆污染情况？@SafeVarargs如果我没有以丢失输入信息或错误混合类型的方式转换变量，我是否有理由使用？换句话说，我是否有理由将此警告视为不是很重要的形式？

程序遇到了不可能的执行例程，if( len >= sizeof(buff) )在现实中不应该是真的，但是它发生了。如printf输出len:-1__1024:所示len，其值为 -1，大于 sizeof(buff)1024。这很神奇。

以下是执行代码。

我认为这个错误是由于堆栈污染造成的，但很难找出其中的秘密。更重要的是，我列出了 function 的代码get_next_event。希望得到您的帮助^_^

I have been looking at various answers and articles regarding heap pollution when using non-reifiable varargs parameters. All examples I have found use an Object[] conversion followed by an array element write. The heap pollution only ever seems to occur in this manner, for example:

Some other articles (such as this SO answer) also appear to be incorrect or entirely misleading:

So now we have a List<String> that actually contains an Integer, and it's floating around, safely.

The code presented in the answer never modifies the lists themselves, just the temporary varargs array within the faultyMethod scope. This runnable demo shows that neither of the two lists are ever polluted and both retain their original String objects (contrary to the answer suggesting they are polluted with an Integer).

I now have two resulting questions:

1. Why does the compiler need to warn us on every possible method when the vast majority of them will not be converting to Object[] - surely it would be better to only warn on the problematic Object[] line itself? Perhaps there is a scenario where "possible heap pollution from parameterized vararg type" can occur without any explicit Object[] conversion?

2. Is the answer to the previous SO question incorrect or am I misinterpreting the statement?