On 23 February 2012 13:43, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > On Thu, Feb 23, 2012 at 12:47:15PM +0000, sebb wrote: >> On 23 February 2012 12:10, Gilles Sadowski <gil...@harfang.homelinux.org> >> wrote: >> > On Thu, Feb 23, 2012 at 11:32:54AM +0000, sebb wrote: >> >> On 23 February 2012 11:19, Gilles Sadowski <gil...@harfang.homelinux.org> >> >> wrote: >> >> > On Thu, Feb 23, 2012 at 10:55:51AM +0000, sebb wrote: >> >> >> On 16 February 2012 16:17, <l...@apache.org> wrote: >> >> >> > Author: luc >> >> >> > Date: Thu Feb 16 16:17:14 2012 >> >> >> > New Revision: 1245061 >> >> >> > >> >> >> > URL: http://svn.apache.org/viewvc?rev=1245061&view=rev >> >> >> > Log: >> >> >> > Removed unneeded clone. >> >> >> > >> >> >> > The clone did not protect the array used, only the reference ones. >> >> >> > JIRA: MATH-650 >> >> >> >> >> >> -1 >> >> >> >> >> >> That was the whole point of the clone - to protect the original >> >> >> external data. >> >> > >> >> > Please (re-)explain what you mean by "protect". Cf. my comment on the >> >> > JIRA page. >> >> >> >> See also your comment of 30/Nov/11 00:31. >> > >> > I know, but my latest comment overrides that one. >> > >> >> The arrays in FastMathLiteralArrays are private, but the access >> >> methods are not, and returning an array allows the caller to modify >> >> array elements. >> > >> > It's true, but unless I'm mistaken, it doesn't matter since in the end >> > there >> > is one and only one array that will be _used_ (the modified one) and having >> > a pristine copy somewhere else will not prevent the dire consequences of >> > using the modified one... ;-/ >> >> Not sure I follow that. >> >> Without clone, the array entries can be changed at any time. >> >> With clone, there are two pristine copies; neither can be changed >> directly as they are stored in private arrays. > > The question is: Why calling "clone"? > The answer is: You get a copy and you cannot change the array stored in > "FastMathLiteralArrays". > But that doesn't save you from the bug that consists in changing an array > entry from within "FastMath". > If that potential bug exists, some methods will produce erroneous values > because they use the copy, not the pristine original array stored in > "FastMathLiteralArrays". [After loading, the original array is never > accessed again.] > > Now if you just obtain a reference to the original array (i.e. no call to > "clone"), the bug will indeed modify it. > But the consequences are not worse than in the above scenario: The exact > same erroneous values will be computed.
Not strictly true, because it's not only the FastMath class that can corrupt the array. Of course clone does not protect against bugs in FastMath; only array entry getters can do that. But that's not the point; since the arrays were (at your insistence) moved out of FastMath itself, this necessarily meant exposing the contents to some degree. Using clone closes that potential exposure - as would using array entry getters. >> >> >> If you don't want the memory overhead of a clone, then one could use >> >> array entry getters instead. >> > >> > It's not that: It is because "clone" gives a false sense of security. >> >> How so? > > Cf. above. > >> >> Are you saying that someone can change the original array entries by >> accessing the cloned copy? > > Certainly not! > > Gilles > >> > Yes, getters would be _really_ secure, as they would prevent an inadvertant >> > CM developer to commit a bug in the "FastMath" class. But a _user_ of >> > "FastMath" can anyways never access the arrays (as the references/copies >> > are >> > "private" to "FastMath"), so I was wondering whether the additional layer >> > of >> > security was really worth it (in case a performance loss would accompany >> > the >> > getters; if not, then fine, fine). >> > >> > >> > Gilles >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
