On Wed, 2007-01-03 at 17:42 -0500, Tomas Restrepo wrote:
> I'm guessing it's Section 4.2.5.3 "Strings". I also agree the term longstr
> is misleading, but the spec does talk about "short and long strings".
>
> Actually, the spec is far more misleading, because it explicitly says that
> "short stri
Alan,
> +1, longstr is misleading and it is entirely unfair to blame C
> programmers! The type in question is a length-prefixed byte array. There
> are no guarantees in the spec about being able to treat it as any type
> of string.
>
> I did a quick search and couldn't find a formal definition f
Alan Conway wrote:
On Wed, 2006-12-20 at 19:14 +, Robert Greig wrote:
On 20/12/06, Kim van der Riet <[EMAIL PROTECTED]> wrote:
Ok, will do - byte[] it is.
Perhaps we should change the term "longstr" in the spec to "binary" or
something similar. It would be less confusing.
I
On Wed, 2006-12-20 at 19:14 +, Robert Greig wrote:
> On 20/12/06, Kim van der Riet <[EMAIL PROTECTED]> wrote:
> > Ok, will do - byte[] it is.
> >
> > Perhaps we should change the term "longstr" in the spec to "binary" or
> > something similar. It would be less confusing.
>
> I fully agree. I t
On 20/12/06, Kim van der Riet <[EMAIL PROTECTED]> wrote:
Ok, will do - byte[] it is.
Perhaps we should change the term "longstr" in the spec to "binary" or
something similar. It would be less confusing.
I fully agree. I tried arguing this point in the past without any
success. I think the argu
Ok, will do - byte[] it is.
Perhaps we should change the term "longstr" in the spec to "binary" or
something similar. It would be less confusing.
Kim
On Wed, 2006-12-20 at 19:08 +, Robert Greig wrote:
> On 20/12/06, Kim van der Riet <[EMAIL PROTECTED]> wrote:
>
> > If we keep String, then
>
On 20/12/06, Kim van der Riet <[EMAIL PROTECTED]> wrote:
If we keep String, then
String.getBytes() produces byte[], and
new String(byte[]) gets a String.
Will this work for security tokens? I am uncertain of the integrity of
this conversion (but a test will soon prove it).
String.getBytes() d
On Wed, 2006-12-20 at 18:19 +, Robert Greig wrote:
> On 20/12/06, Kim van der Riet <[EMAIL PROTECTED]> wrote:
>
> > Is it correct to keep the mapping in the new generator of longstr to
> > String, or should it be kept as byte[]? I had anticipated that longstr
> > may find wider usage besides s
On 20/12/06, Kim van der Riet <[EMAIL PROTECTED]> wrote:
Is it correct to keep the mapping in the new generator of longstr to
String, or should it be kept as byte[]? I had anticipated that longstr
may find wider usage besides security tokens.
We need to be able to transfer a byte[] for the sec
On 20/12/06, Kim van der Riet <[EMAIL PROTECTED]> wrote:
On Wed, 2006-12-20 at 15:48 +, Martin Ritchie wrote:
> A longstr needs to be capable of handling 2-byte characters while the
> shorstr only deals with ASCII values. I thought String was an ASCII
> string only if that is the case then lo
On Wed, 2006-12-20 at 15:48 +, Martin Ritchie wrote:
> A longstr needs to be capable of handling 2-byte characters while the
> shorstr only deals with ASCII values. I thought String was an ASCII
> string only if that is the case then longstr will need to stay as a
> byte[].
I had thought that S
A longstr needs to be capable of handling 2-byte characters while the
shorstr only deals with ASCII values. I thought String was an ASCII
string only if that is the case then longstr will need to stay as a
byte[].
On 20/12/06, Kim van der Riet <[EMAIL PROTECTED]> wrote:
I am working on integrati
I am working on integrating the new code generator into the Java
implementation.
I notice that in the old XSL-based generator, longstr is mapped to java
type byte[] while shortstr is mapped to String. In the new generator,
both shortstr and longstr are mapped to String. I also notice that in
the 0
13 matches
Mail list logo
