Mailing-List: contact batik-dev-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: batik-dev@xmlgraphics.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Tue, 20 Jun 2006 15:20:28 +0200
From: Jeremias Maerki <dev@jeremias-maerki.ch>
To: batik-dev@xmlgraphics.apache.org
Subject: Re: DO NOT REPLY [Bug 39838]  New:  - patches to prevent integer
 overflow
In-Reply-To: <20060620131509.GA8685@port.mcc.id.au>
References: <20060620100208.7885.DEV@jeremias-maerki.ch>
 <20060620131509.GA8685@port.mcc.id.au>
Message-Id: <20060620151538.789C.DEV@jeremias-maerki.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


On 20.06.2006 15:15:09 Cameron McCormack wrote:
> Jeremias Maerki:
> > you are now a committer in Batik. You can apply these changes yourself
> > if you think they don't need to be discussed (commit-review). The
> > approach you've chosen is only necessary if you have a change that coul=
d
> > be subject for discussion (review-commit).
>=20
> Oh and another thing I meant to mention, Dieter.  Any file that you make
> any changes to (that aren=92t trivial reformatting or something similarly
> small) should have its copyright message updated so that the current
> year is included.

Actually, that's not important anymore. Shortly, there will be an
announcement about a policy change concerning the license header. It
will be changed again and the new one will not have a copyright year
anymore. Cliff Schmidt (ASF VP, legal affairs) is currently finalizing
all necessary information. Stay tuned.

> One thing in the code:
>=20
>   Index: org/apache/batik/css/engine/StringIntMap.java
>   =85
>   -       if (count++ >=3D (len * 3) >>> 2) {
>   +       if (count++ >=3D len - ( len >>> 2 )) {
>=20
> Note that these two expressions are slightly different.  For example
> when len =3D=3D 5, the first expression checks >=3D 3, while the second c=
hecks
> >=3D 4.  It doesn=92t really matter in this case, though, since it=92s ju=
st
> used as a rough check for when the hash table is getting full.  If you
> realised this, don=92t mind me.
>=20
> Thinking aloud: should we have a code style policy, as FOP does?

Doesn't hurt. :-) I guess we will need one for XML Graphics Commons
unless we want a wide range of styles. But even in FOP we haven't fixed
all style "violations", yet.

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org