commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: svn commit: r1245061 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/util/FastMathLiteralArrays.java
Date Thu, 23 Feb 2012 13:43:57 GMT
On Thu, Feb 23, 2012 at 12:47:15PM +0000, sebb wrote:
> On 23 February 2012 12:10, Gilles Sadowski <gilles@harfang.homelinux.org> wrote:
> > On Thu, Feb 23, 2012 at 11:32:54AM +0000, sebb wrote:
> >> On 23 February 2012 11:19, Gilles Sadowski <gilles@harfang.homelinux.org>
wrote:
> >> > On Thu, Feb 23, 2012 at 10:55:51AM +0000, sebb wrote:
> >> >> On 16 February 2012 16:17,  <luc@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.

> 
> >> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message