Inconsistency between liftToSMT and isSat when MEMORY_ARRAY is enabled about triton

[NVThufv]

Yes I think the additional modes are helpful. The following snippet for tritonToZ3.cpp may help

case ARRAY_NODE: {
	auto size  = triton::ast::getInteger<triton::uint32>(node->getChildren()[0]);
	auto isort = this->context.bv_sort(size);
	if(MODE.MEMORY_CONST_ARRAY){
		auto value = this->context.bv_val(0, 8);
		return to_expr(this->context, Z3_mk_const_array(this->context, isort, value));
	} else if(MODE.MEMORY_ARRAY){
		auto vsort = this->context.bv_sort(8);
		auto arraySort = this->context.array_sort(isort, vsort);
		return this->context.constant("memory", arraySort);
	}
}

(Of course, the model collecting mechanism in z3solver.cpp and other related codes may need additional adjustment, since it will result in non-bv sort elements like memory).

[JonathanSalwan]

Indeed, this is because we consider array as const array with a default value 0, like it's pretty much the case when you spawn a process with uninitialized memory. We chosen to define this array as const, otherwise every cell's content is consider as symbolic by the SMT solver which is problematic in several cases.

However, I understand that for some cases, you might want to have these cell's content symbolic. Maybe we can have two modes for this, like MEMORY_CONST_ARRAY and MEMORY_ARRAY ?