It seems that object behaviors have a problem with named arguments. Attempting to use them causes a crash due to a null pointer.

Specifically, the problem is that the behavior's function doesn't have a valid parameterNames array. I've isolated the problem to the asCScriptEngine::AddBehaviourFunction method:

asCScriptFunction *f = asNEW(asCScriptFunction)(this, 0, asFUNC_SYSTEM);
if( f == 0 )
{
	asDELETE(newInterface, asSSystemFunctionInterface);
	return asOUT_OF_MEMORY;
}

asASSERT(func.name != "" && func.name != "f");
f->name           = func.name;
f->sysFuncIntf    = newInterface;
f->returnType     = func.returnType;
f->objectType     = func.objectType;
if( f->objectType )
	f->objectType->AddRefInternal();
f->id             = id;
f->isReadOnly     = func.isReadOnly;
f->accessMask     = defaultAccessMask;
f->parameterTypes = func.parameterTypes;
f->inOutFlags     = func.inOutFlags;
for( n = 0; n < func.defaultArgs.GetLength(); n++ )
	if( func.defaultArgs[n] )
		f->defaultArgs.PushLast(asNEW(asCString)(*func.defaultArgs[n]));
	else
		f->defaultArgs.PushLast(0);

AddScriptFunction(f);

The parameterNames variable is never copied over, so when the compiler tries to access it, it gets a null string from the array, which then triggers the exception when it is compared to a named argument.

This may also be a problem with regular methods, i haven't tested that. Presumably that is the case though.

Thanks. I'll look into this.

To save some time, do you have a script sample that reproduces the problem?

The smallest program that still reproduces it requires a change to the array constructor that constructs an array of a given number of elements. The parameters need to be named:

r = engine->RegisterObjectBehaviour("array<T>", asBEHAVE_FACTORY, "array<T>@ f(int&in, uint count, const T &in value)", asFUNCTIONPR(CScriptArray::Create, (asIObjectType*, asUINT, void *), CScriptArray*), asCALL_CDECL); assert( r >= 0 );

The following script code will then cause a null pointer exception:

void test()
{
	array<string> a( 10, value: "foo" );
}

Thanks.

I've fixed the problem now in revision 2249.