Dnia 25-01-2008, Pt o godzinie 22:16 +, Mark Wielaard pisze:
> Hi Robert,
>
> Robert Lougher <[EMAIL PROTECTED]> writes:
> > This is getting a bit hostile for no reason Thinking about
> > alignment gives an interesting solution.
> >
> > 1) Strings are not null-terminated
> > 2) For most
Hi Mark,
On Jan 25, 2008 10:16 PM, Mark Wielaard <[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> Robert Lougher <[EMAIL PROTECTED]> writes:
> > This is getting a bit hostile for no reason Thinking about
> > alignment gives an interesting solution.
> >
> > 1) Strings are not null-terminated
> > 2)
Hi Robert,
Robert Lougher <[EMAIL PROTECTED]> writes:
> This is getting a bit hostile for no reason Thinking about
> alignment gives an interesting solution.
>
> 1) Strings are not null-terminated
> 2) For most strings the alignment gives the VM room to terminate in
> place when GetStringCha
On 1/25/08, Clemens Eisserer <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> > This is getting a bit hostile for no reason Thinking about
> > alignment gives an interesting solution.
> >
> > 1) Strings are not null-terminated
> > 2) For most strings the alignment gives the VM room to terminate in
>
he String (it's unpinned in ReleaseStringChars).
Rob.
P.S. I hope your blindfold has been removed :) When implementing a VM few
things are as straight-forward as they may seem.
--
View this message in context:
http://www.nabble.com/Null-terminated-Unicode-strings-in-java.io-on-Windows-tp15006673p15091812.html
Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com.
Hi there,
> This is getting a bit hostile for no reason Thinking about
> alignment gives an interesting solution.
>
> 1) Strings are not null-terminated
> 2) For most strings the alignment gives the VM room to terminate in
> place when GetStringChars is called
> 3) Copy strings that can't be
Hi,
This is getting a bit hostile for no reason Thinking about
alignment gives an interesting solution.
1) Strings are not null-terminated
2) For most strings the alignment gives the VM room to terminate in
place when GetStringChars is called
3) Copy strings that can't be terminated in place
Dnia 25-01-2008, Pt o godzinie 18:44 +0100, Roman Kennke pisze:
> Heyo,
>
> > > The specification is buggy
> > > > in that it does not take into account the operating system interface
> > > > and makes correct memory management inefficient
> > > > for the benefit of sparing one byte per buffer
Dnia 25-01-2008, Pt o godzinie 18:54 +0100, Roman Kennke pisze:
> Hi,
>
> > Please observe:
> >
> > 1.
> > the amount of memory needed to manage the allocation
> > is greater than the number of bytes
> > needed to store one additional character,
> > so the relative impact on memory usage wi
Hi Chris,
On 1/25/08, Krzysztof Żelechowski <[EMAIL PROTECTED]> wrote:
>
> Dnia 25-01-2008, Pt o godzinie 17:30 +, Robert Lougher pisze:
> > No it doesn't. An implementation would have to be truly stupid to
> > internally null-terminate. How many Strings are in the heap? How
> > many will t
Hi,
> Please observe:
>
> 1.
> the amount of memory needed to manage the allocation
> is greater than the number of bytes
> needed to store one additional character,
> so the relative impact on memory usage will not be dramatic.
This is just ridiculous. An average Java app has tons of Strin
Heyo,
> > The specification is buggy
> > > in that it does not take into account the operating system interface
> > > and makes correct memory management inefficient
> > > for the benefit of sparing one byte per buffer
> > > where an OS call is not needed.
> > > Ridiculous.
> >
> > Tom Tromey
Dnia 25-01-2008, Pt o godzinie 17:30 +, Robert Lougher pisze:
> No it doesn't. An implementation would have to be truly stupid to
> internally null-terminate. How many Strings are in the heap? How
> many will the programmer access via GetStringChars? The null will be
> a overhead for all S
On 1/25/08, Krzysztof Żelechowski <[EMAIL PROTECTED]> wrote:
>
> Dnia 25-01-2008, Pt o godzinie 17:08 +, Robert Lougher pisze:
> > Hi,
>
> Hi-aye.
>
> >
> > Apologies if you receive this twice. I sent it via nabble and it's
> > now stuck awaiting moderation so I've subscribed.
> >
> >
> >
> >
Dnia 25-01-2008, Pt o godzinie 18:19 +0100, Roman Kennke pisze:
> Hi,
>
> > The specification is buggy
> > in that it does not take into account the operating system interface
> > and makes correct memory management inefficient
> > for the benefit of sparing one byte per buffer
> > where an OS
Dnia 25-01-2008, Pt o godzinie 17:08 +, Robert Lougher pisze:
> Hi,
Hi-aye.
>
> Apologies if you receive this twice. I sent it via nabble and it's
> now stuck awaiting moderation so I've subscribed.
>
>
>
> Dnia 25-01-2008, Pt o godzinie 13:14 +, Mark Wielaard pisze:
> > Krzysztof Ż
Hi,
> The specification is buggy
> in that it does not take into account the operating system interface
> and makes correct memory management inefficient
> for the benefit of sparing one byte per buffer
> where an OS call is not needed.
> Ridiculous.
Tom Tromey pointed out another possible pro
Hi,
> The specification is buggy
> in that it does not take into account the operating system interface
> and makes correct memory management inefficient
> for the benefit of sparing one byte per buffer
> where an OS call is not needed.
> Ridiculous.
> The developers at Sun
> found the correct way
Hi,
Apologies if you receive this twice. I sent it via nabble and it's
now stuck awaiting moderation so I've subscribed.
Dnia 25-01-2008, Pt o godzinie 13:14 +, Mark Wielaard pisze:
> Krzysztof Żelechowski <[EMAIL PROTECTED]> writes:
> > If the specification gets fixed so that GSC result M
Roman Kennke wrote:
Hi Alan,
Am Montag, den 21.01.2008, 21:52 + schrieb Alan Bateman:
:
The GetStringChars implementation in HotSpot always returns a copy that
is length+1 and zero terminated. There is a long-standing bug to clarify
the JNI specification on this topic. I believe it sho
Hi Roman,
Roman Kennke <[EMAIL PROTECTED]> writes:
> Hmm, I'm not talking about fixing the spec (I've read that bug report
> while searching for clarfication on the spec actually). When the spec
> doesn't tell _that_ the returned array is zero terminated, I think we
> should assume that it isn't (a
Dnia 25-01-2008, Pt o godzinie 13:14 +, Mark Wielaard pisze:
> Krzysztof Żelechowski <[EMAIL PROTECTED]> writes:
> > If the specification gets fixed so that GSC result MUST be z-term,
> > your VM will cease being conformant
> > so it will be fixed and no additional buffers will be needed.
>
Krzysztof Żelechowski <[EMAIL PROTECTED]> writes:
> If the specification gets fixed so that GSC result MUST be z-term,
> your VM will cease being conformant
> so it will be fixed and no additional buffers will be needed.
Eh, that doesn't seem right at all.
The specification currently doesn't gu
Dnia 21-01-2008, Pn o godzinie 23:57 +0100, Roman Kennke pisze:
> Hi,
>
> Am Montag, den 21.01.2008, 14:45 -0800 schrieb Tim Bell:
> > Alan Bateman wrote (about GetStringChars):
> >
> > > [...] is length+1 and zero terminated. There is a long-standing bug to
> > > clarify the JNI specification
Hi,
Am Montag, den 21.01.2008, 14:45 -0800 schrieb Tim Bell:
> Alan Bateman wrote (about GetStringChars):
>
> > [...] is length+1 and zero terminated. There is a long-standing bug to
> > clarify the JNI specification on this topic. I believe it should say that
> > the returned array of Unicode
Alan Bateman wrote (about GetStringChars):
[...] is length+1 and zero terminated. There is a long-standing bug to clarify
the JNI specification on this topic. I believe it should say that the returned
array of Unicode characters is not required to be zero terminated and that one
should use Ge
Hi Alan,
Am Montag, den 21.01.2008, 21:52 + schrieb Alan Bateman:
> Roman Kennke wrote:
> > Hi,
> >
> > I'm trying to understand a piece of code in java.io . Let me try to
> > explain:
> >
> > When you look into WinNTFileSystem.c in the method
> > getBooleanAttributes(), you see that the file
Roman Kennke wrote:
Hi,
I'm trying to understand a piece of code in java.io . Let me try to
explain:
When you look into WinNTFileSystem.c in the method
getBooleanAttributes(), you see that the file object is converted to a
WCHAR* using fileToNTPath(). In io_util.c, fileToNTPath(), the filename
Hi,
I'm trying to understand a piece of code in java.io . Let me try to
explain:
When you look into WinNTFileSystem.c in the method
getBooleanAttributes(), you see that the file object is converted to a
WCHAR* using fileToNTPath(). In io_util.c, fileToNTPath(), the filename
string is extracted fr
29 matches
Mail list logo
