toString – Talk
(→This page is bugged?: new section) |
Lou Montana (talk | contribs) m (Text replacement - " ArmA2 " to " Arma 2 ") |
||
Line 1: | Line 1: | ||
Roehre wrote... | Roehre 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 ? |
Revision as of 03:04, 2 January 2021
Roehre 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. 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)
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)