toString – Talk
RoehrenRadio (talk | contribs) mNo edit summary |
Lou Montana (talk | contribs) m (Text replacement - "[Rr]oehre" to "RoehrenRadio") |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
RoehrenRadio wrote... | |||
More nonsense in | More nonsense in Arma 2 1.05 Final : The number zero in the array to convert will end the String. | ||
[[User:Sbsmac|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 ? | [[User:Sbsmac|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 ? | ||
| Line 8: | Line 8: | ||
[124, 324, -1249, 3249, -1, 0, 324, 41824] - toString -> "|ńײַಱ￿" - toArray -> [124,324,64287,3249,65535] = W-T-F? | [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? | 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: | 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:RoehrenRadio|RoehrenRadio]] | ||
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) | |||
== This page is bugged? == | |||
See also wont work. I even copied over another entire command page source and still the see also doesnt work. I only used preview. Can anyone else confirm this too? <br>[[User:Benargee|Benargee]] ([[User talk:Benargee|talk]]) 05:55, 27 September 2014 (CEST) | |||
Latest revision as of 10:49, 8 April 2024
RoehrenRadio wrote...
More nonsense in Arma 2 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. RoehrenRadio
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)
This page is bugged?
See also wont work. I even copied over another entire command page source and still the see also doesnt work. I only used preview. Can anyone else confirm this too?
Benargee (talk) 05:55, 27 September 2014 (CEST)