Is WString broken?

[Tim_Hare]

Just to be perfectly clear, w.len should not equal 18. It should be 17, as I said.

Ah. What threw me is you said “bytes”, not “characters”. A WString should always be an even number of bytes. I didn’t read your post closely enough. Sorry.

[Kem_Tekinay]

@128421:@Michel Bujardet

Why unnecessary ?

For reasons I am not at liberty to discuss or disclose.

[brian_franco]

@128447:@Kem Tekinay

For reasons I am not at liberty to discuss or disclose.

Kem are you working on that Nuclear WString project?

[Tim_Hare]

@128445:@Kem Tekinay

For me academic. But if I (or anyone) needed to call an external function that expected or returned such a value, this would come into play. That’s the conversation that sparked my curiosity.

I think the code in the other thread is flawed. He’s doing a lot of unnecessary conversions. Return values should work correctly since they will be well-formed.

Plus, I can’t get WString to malfunction.

[Charles_Yeomans]

@128422:@Randy Baskin

It clearly did happen. If you stop the debugger after the string literal is assigned to the wstring, you will see a null terminator added (if you look at its binary representation. The length of the wstring is 17 bytes. The length of the string literal and the “s” var is 16 bytes. What are you looking at?

I’m looking at this code

dim w as WString = "this is a string"

in the Xojo 2014r2 debugger. I can certainly produce bad behavior.

[Tim_Hare]

[quote=128450:@Charles Yeomans]I’m looking at this code

dim w as WString = "this is a string"

in the Xojo 2014r2 debugger. I can certainly produce bad behavior.[/quote]
What platform? That code produces the correct result on Windows 7, Xojo 2014r2 and 2014r2.1

What are the byte values you see? I get
7400 6800 6900 7300 2000
6900 7300 2000 6100 2000
7300 7400 7200 6900 6E00
6700 0000

[Kem_Tekinay]

I’m starting to think this is a Mac-only problem.

[Charles_Yeomans]

[quote=128453:@Tim Hare]What platform? That code produces the correct result on Windows 7, Xojo 2014r2 and 2014r2.1

What are the byte values you see? I get
7400 6800 6900 7300 2000
6900 7300 2000 6100 2000
7300 7400 7200 6900 6E00
6700 0000[/quote]

I was testing on Mac OS 10.9.4, as I think I mentioned earlier. WString works fine in Windows builds; the problem is other platforms.

[Randy_Baskin]

@128446:@Tim Hare

Ah. What threw me is you said “bytes”, not “characters”. A WString should always be an even number of bytes. I didn’t read your post closely enough. Sorry.

Yes, you’re correct. I should be more careful with my terms when referring to strings.

Way back when I first I started coding, double-byte character sets didn’t really exist. It was mostly just EBCDIC and ASCII. Back then, when referring to strings, bytes and characters were synonymous. So sometimes, I fall back into the that old school way of talking about strings.

I really do need to be more careful – especially when discussing different types of encodings.

[Kem_Tekinay]

@128459:@Randy Baskin

Back then, when referring to strings, bytes and characters were synonymous. So sometimes, I fall back into the that old school way of talking about strings.

You’re certainly not alone.

[Michel_Bujardet]

[quote=128372:@Kem Tekinay]I never use WString, but based on another conversation here, I had occasion to try it. And I don’t get it.

Based on my understanding, this should work:

  dim w as WString = "this is a string"
  dim s as string = w

But what I get in both w and s is just trash with only a mild resemblance to my original string. Where have I gone wrong?[/quote]

It works perfectly on Windows 8.1, but on Mac the string becomes garbage. It is a bug.

<https://xojo.com/issue/35303>

A possible workaround could be to use an UTF-16 string and add to it the terminating chr(0).