Consider your code here:
Code:
decl String:buffer[100];
buffer = "This is a string";
In SourcePawn, the second line changes the array pointer address to whatever "this is a string" ends up becoming, but does not actually change the string in memory. Basically, your array will point at a new, meaningless location in memory, which your script will have no problem reading from, and will be printed out as gibberish.
The following are acceptable:
Code:
new String:buffer[100] = "This is a string"; // Assignment like this during creation is acceptable
new String:buffer_2[] = "This is also a string"; // buffer_2's length will be auto-sized
decl String:buffer_3[100];
strcopy(buffer_3, "This is another string");
Similarly, you have to use the function "StrEqual(string_1, string_2)" to do logical comparisons of strings.
Languages that accept the straight-on assignment like you propose , such as PHP, are actually interpreting your intent in the compiler and sort of correct the logic to do what you would intuitively expect - assign the string into the array, and not change the memory address. SourcePawn doesn't do that for you.
The reason you get a LOT of gibberish output is because the script is actually reading from memory until it encounters the end-of-string character , '/0'. This character is automatically appended to all strings in memory, and this why a 2-character string like "at" actually takes 3 bytes. This system trusts that the provided memory address is valid, however, and it has no defense against random selection of a new memory address other than to keep reading until it happens across another end-of-string character from another string in memory.
Though I don't know the source code, I would expect strcopy(dest, source) to be faster than a pass-through with Format and is preferred unless your new string requires complex combination of several sources.
Linear Mode
