Error messages update

[MiranDMC]

Text argument type names in error messages
Added pointer minimal value validation when reading or writing string params.

[x87]

Suggested change

	size_t length = bufSize ? bufSize - 1 : 0; // minus terminator char
	if (opcodeParams[0].dwParam == 0)
	{
	length = 0;
	LOG_WARNING("Reading string from null pointer in script %s", ((CCustomScript*)thread)->GetInfoStr().c_str());
	const char* eStr = "(null)";
	length = min(length, strlen(eStr));
	if (length) strncpy(buf, eStr, length);
	}
	else if(opcodeParams[0].dwParam <= CCustomOpcodeSystem::MinValidAddress)
	{
	LOG_WARNING("Reading string from argument with invalid pointer value (0x%X) in script %s", opcodeParams[0].dwParam, ((CCustomScript*)thread)->GetInfoStr().c_str());
	const char* eStr = "(badPtr)";
	length = min(length, strlen(eStr));
	if (length) strncpy(buf, eStr, length);
	return nullptr; // error
	}
	if(bufSize > 0)
	length = min(length, bufSize - 1); // minus terminator char
	else
	length = 0; // no target buffer
	{
	char* str = opcodeParams[0].pcParam;
	length = min(length, strlen(str));
	if (length) strncpy(buf, str, length);
	}
	if(opcodeParams[0].dwParam <= CCustomOpcodeSystem::MinValidAddress)
	{
	return nullptr; // error
	}
	else
	{
	char* str = opcodeParams[0].pcParam;
	size_t length = min(bufSize ? bufSize - 1 : 0, strlen(str));
	if (length) strncpy(buf, str, length);
	}

[MiranDMC]

I added read string from nullptr as error in previous version, and after some using it I decided it is not what I like. It is common case when you can have text pointer or null returned from somewhere, and not necessary you always care what it is, just use it to print. Old '(null)' returning behaviour was fine after all, but printing ptr like 0x5 is of course some logic error.

I would like to keep "Reading string from argument with invalid pointer value (x)" error message too.

[x87]

I see. I would prefer an empty string instead, as it feels more natural, but still better than a crash.

Pointer validation should be done on the script side anyway (if you get it from somewhere), so we can state that providing a nullptr is UB (undefined behavior) and could change in the future. Today it may return (null), tomorrow an empty string, next week it could do something else. Would you be able to add a comment on top of this check, that this behavior is subject to change without notice?

[MiranDMC]

It was always returning '(null)' and now I'm convinced there is no need to change it:

• It will be 100% backward compatible if someone depended on it
• Returning empty string will make more difficult to understand what is going on, (null) catches eye immediately.

[MiranDMC]

The pointer range check is meant to catch most frequent mistakes in form of:
print_formatted "My value %s" 0@ where %d should be used instead