Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 31751 invoked from network); 16 Feb 2006 14:39:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 16 Feb 2006 14:39:35 -0000 Received: (qmail 49201 invoked by uid 500); 16 Feb 2006 14:39:12 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 49077 invoked by uid 500); 16 Feb 2006 14:39:12 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 49047 invoked by uid 99); 16 Feb 2006 14:39:11 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Feb 2006 06:39:11 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of m.v.lunteren@gmail.com designates 64.233.182.194 as permitted sender) Received: from [64.233.182.194] (HELO nproxy.gmail.com) (64.233.182.194) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Feb 2006 06:39:10 -0800 Received: by nproxy.gmail.com with SMTP id l35so115906nfa for ; Thu, 16 Feb 2006 06:38:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Lnf6QjjVYoRZbyU8aYs4xA1pTkXLvss/Vt08Xt50kbdSLRPWahZ9GPwm75pjbYVHvq/cct1/98iACoSSbux0ggxi0DUNLbJXj770wtt/CQZVjQ+fjkSkax1/EWOetmhAeL8BeFzREMfeoJfxAUalGSZvfEpP0PzzduunMlRYrQU= Received: by 10.49.80.12 with SMTP id h12mr177675nfl; Thu, 16 Feb 2006 06:38:48 -0800 (PST) Received: by 10.48.48.15 with HTTP; Thu, 16 Feb 2006 06:38:48 -0800 (PST) Message-ID: Date: Thu, 16 Feb 2006 06:38:48 -0800 From: Myrna van Lunteren To: derby-dev@db.apache.org Subject: Re: [jira] Commented: (DERBY-902) Remove use of String(byte[]) and String(byte[], int, int) constructors in engine leading to non-portable behaviour In-Reply-To: <1331460012.1139876084935.JavaMail.jira@ajax.apache.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18819_19581608.1140100728946" References: <108911104.1138741292940.JavaMail.jira@ajax.apache.org> <1331460012.1139876084935.JavaMail.jira@ajax.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_18819_19581608.1140100728946 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I was just composing a comment when JIRA took a breather. This is what I wanted to say: I've looked into this (and experimented) a bit more. This string is only ever used within NetworkServer, so I don't see how it could be a problem in other encodings, or am I missing something in my understanding of how this works? It seems to me it does not matter much what the content of the String in question is, as long as it 1. is identical to what's assigned to SQLERRMC_MESSAGE_DELIMITER in java/drda/org/apache/derby/impl/drda/DRDAConnThread 2. is short (comments in DRDAConnThread indicate CCC can only handle up to 70 characters of errors concatenated with this string) 3. can never be found in any error messages. So, there are 2 alternatives: 1. leave the string as is, and add a comment indicating it's only used internally in network server. 2. replace the string with something else, in both classes, for instance, String errSeparator=3D":;:" Please advise, I can make another patch with whichever alternative is preferred. Myrna On 2/13/06, Daniel John Debrunner (JIRA) wrote: > > [ > http://issues.apache.org/jira/browse/DERBY-902?page=3Dcomments#action_123= 66266] > > Daniel John Debrunner commented on DERBY-902: > --------------------------------------------- > > Thanks Kathey for pointing that out, I was wrong, I saw the > > byte[] b =3D {20, 20, 20}; > > and I mentally assumed they were 0x20, which would correspond to the spac= e > character. > > > Remove use of String(byte[]) and String(byte[], int, int) constructors > in engine leading to non-portable behaviour > > > -------------------------------------------------------------------------= ----------------------------------------- > > > > Key: DERBY-902 > > URL: http://issues.apache.org/jira/browse/DERBY-902 > > Project: Derby > > Type: Bug > > Components: Network Server > > Reporter: Daniel John Debrunner > > Fix For: 10.2.0.0 > > Attachments: DERBY-902_021306.stat, DERBY-902_021306_2.diff > > > > These constructors use the Java default platform encoding to convert th= e > bytes to a String, this typically leads to bugs on platforms with differe= nt > encodings. > > Replace with code using fixed conversion, or alternative mechanisms. > > If the call is required its use should be commented as to why it is > required. > > org.apache.derby.catalog.SystemProcedures > > I generated this list using the Java search in eclipse for references t= o > the constructors > > String(byte[]) > > String(byte[],int,int) - no occurrrences in java/engine > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: > http://www.atlassian.com/software/jira > > ------=_Part_18819_19581608.1140100728946 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I was just composing a comment when JIRA took a breather.
 
This is what I wanted to say:
I've looked into this (and experimented) a bit more.
 
This string is only ever used within NetworkServer, so I don't see how= it could be a problem in other encodings, or am I missing something in my = understanding of how this works?
 
It seems to me it does not matter much what the content of the String = in question is, as long as it
1. is identical to what's assigned to SQLERRMC_MESSAGE_DELIMITER = in java/drda/org/apache/derby/impl/drda/DRDAConnThread
2. is short (comments in DRDAConnThread indicate CCC can only handle u= p to 70 characters of errors concatenated with this string) 
3. can never be found in any error messages.
 
So, there are 2 alternatives:
1. leave the string as is, and add a comment indicating it's only= used internally in network server.
2. replace the string with something= else, in both classes, for instance,
      String errSeparator=3D":;:"
 
Please advise, I can make another patch with whichever alternative is = preferred.
 
Myrna

 
On 2/13/06, = Daniel John Debrunner (JIRA) <derby-dev@db.apache.org> wrote:
   [ h= ttp://issues.apache.org/jira/browse/DERBY-902?page=3Dcomments#action_123662= 66 ]

Daniel John Debrunner commented on DERBY-902:
------------= ---------------------------------

Thanks Kathey for pointing that ou= t, I was wrong, I saw the

byte[] b =3D {20, 20, 20};

and I me= ntally assumed they were 0x20, which would correspond to the space characte= r.

> Remove use of String(byte[]) and String(byte[], int, int) cons= tructors in engine leading to non-portable behaviour
> --------------= ---------------------------------------------------------------------------= -------------------------
>
>          = ;Key: DERBY-902
>        &nbs= p; URL: htt= p://issues.apache.org/jira/browse/DERBY-902
>   &n= bsp;  Project: Derby
>      &= nbsp;  Type: Bug
>   Components: Network Server
>   &n= bsp; Reporter: Daniel John Debrunner
>     &= nbsp;Fix For: 10.2.0.0
>  A= ttachments: DERBY-902_021306.stat, DERBY-902_021306_2.diff
>
> These constructors use the Java default platform encoding to convert t= he bytes to a String, this typically leads to bugs on platforms with differ= ent encodings.
> Replace with code using fixed conversion, or alterna= tive mechanisms.
> If the call is required its use should be commented as to why it i= s required.
> org.apache.derby.catalog.SystemProcedures
> I gen= erated this list using the Java search in eclipse for references to the con= structors
> String(byte[])
> String(byte[],int,int) - no occurrrences in= java/engine

--
This message is automatically generated by JIRA.<= br>-
If you think it was sent incorrectly contact one of the administrat= ors:
  http://issues.apache.org/jira/secure/Administrators.jspa
-=
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


------=_Part_18819_19581608.1140100728946--