[AndreT]

I think I see a potential problem with the code in CScripting.cpp.

The memory allocated for the output of the C mysql_real_escape_string must be (2*strlen(input))+1. Assuming that you usually know what you're doing, when you write PAWN code, you do this:

pawn Код:

new src[32];
new dest[64];
mysql_real_escape_string(src, dest); // max_len=sizeof(destination) by default

What the plugin native then does is:

pawn Код:

size_t DestLen = (params[4] <= 0 ? 8192 : params[4]); // DestLen becmes 64 (in our case at least)
// ...
char *StrBuffer = (char *)malloc(DestLen*2+1); // Allocates 64*2+1=129 bytes of memory
memset(StrBuffer, 0, DestLen*2 + 1); // Set it all to zeros (?)
cell StringLen = (cell)mysql_real_escape_string(ConnPtr, StrBuffer, Source, strlen(Source));
StrAmx::SetCString(amx, params[2], StrBuffer, params[4]);
free(StrBuffer);

Also, I think that memset needn't be used here - the C mysql_real_escape_string appends a NULL byte by itself. To allocate 64+1 bytes of memory (aka. what we need here to be on the safe side), it needs to make use of the SourceLen variable (cannot exceed 32 in our example) and double it and add 1 byte for the NULL.

I assume this is not going to make a relevant speed difference, and perhaps the AMX interactions with large arrays is just slow, but using heap allocation (alloca instead of malloc) is a possibility here as well. Once again may not make a relevant speed difference, and may even be dangerous (if you start allocating megabytes!)