toString – Talk
RoehrenRadio (talk | contribs) mNo edit summary |
No edit summary |
||
| Line 9: | Line 9: | ||
Note, that the string looks ingame (RTE) completely different from that here, don't know why, maybe Commpressingbugs of "str"-cmd? | Note, that the string looks ingame (RTE) completely different from that here, don't know why, maybe Commpressingbugs of "str"-cmd? | ||
Beside I really can't see the connection of the given UTF-8-Code Table and the Strings, which ArmA generates; So I'm not even able to build a going-around of this bug. Please pardon me, if I'm talking shit, but I'm fed up to the back teeth with BIS and their developing, where I only be able to affiliate the Commands, on a, for me, more or less logical way. [[User:Roehre|Roehre]] | Beside I really can't see the connection of the given UTF-8-Code Table and the Strings, which ArmA generates; So I'm not even able to build a going-around of this bug. Please pardon me, if I'm talking shit, but I'm fed up to the back teeth with BIS and their developing, where I only be able to affiliate the Commands, on a, for me, more or less logical way. [[User:Roehre|Roehre]] | ||
The result is logical: | |||
A string consist of char. In this case is a char two byte. And it is an unsigned integer. | |||
Therefore negative numbers aren't allowed. And 0 is the termination character of a string. | |||
Take a look at the string handling of C++. | |||
So [124, 324, -1249, 3249, -1, 0, 324, 41824] will be converted to [124, 324, 65536-1249, 3249, 65536-1, 0, 324, 41824] = [124, 324, 64287, 3249, 65535, 0, 324, 41824] and if this now will be converted to a string, it will convert all chars, but the string will end at the 0. | |||
Take a look at strings in C++ and how they look in the memory. This will explain it. | |||
--[[User:I0n0s|I0n0s]] 19:31, 19 May 2010 (CEST) | |||
Revision as of 18:31, 19 May 2010
Roehre wrote...
More nonsense in ArmA2 1.05 Final : The number zero in the array to convert will end the String.
Sbsmac Sorry but you are going to have to offer a bit more explanation than that. Why would a null byte in a UTF-8 string NOT be treated as a terminator ?
Why Nullbyte in the UTF-8 String? The Job of this Command, is only to compress an Array of Numbers (what's more nonsense for me) into a String, insofar my Opinion. My problem is, that I'm not able to compress an Array of Numbers, which contains the Number *0* (Zero) or a number beneath. Either it returns a String, which ends at the negative Number (or Zero), or it just compresses shit into a String.
[124, 324, -1249, 3249, -1, 0, 324, 41824] - toString -> "|ńײַಱ￿" - toArray -> [124,324,64287,3249,65535] = W-T-F? Note, that the string looks ingame (RTE) completely different from that here, don't know why, maybe Commpressingbugs of "str"-cmd?
Beside I really can't see the connection of the given UTF-8-Code Table and the Strings, which ArmA generates; So I'm not even able to build a going-around of this bug. Please pardon me, if I'm talking shit, but I'm fed up to the back teeth with BIS and their developing, where I only be able to affiliate the Commands, on a, for me, more or less logical way. Roehre
The result is logical: A string consist of char. In this case is a char two byte. And it is an unsigned integer. Therefore negative numbers aren't allowed. And 0 is the termination character of a string. Take a look at the string handling of C++.
So [124, 324, -1249, 3249, -1, 0, 324, 41824] will be converted to [124, 324, 65536-1249, 3249, 65536-1, 0, 324, 41824] = [124, 324, 64287, 3249, 65535, 0, 324, 41824] and if this now will be converted to a string, it will convert all chars, but the string will end at the 0. Take a look at strings in C++ and how they look in the memory. This will explain it.
--I0n0s 19:31, 19 May 2010 (CEST)