Boolean array assignment in initial equation section

[Adeel Asghar]

Boolean array assignment in initial equation section generates [CodegenC.tpl:8568:16-8568:16:writable] Error: Template error: daeExpRelation:ERR if external object is used in the equation. See the attached model and script.

If there is no external object then it works fine.

[Adeel Asghar]

I tested the same model with real array and it worked fine. But if we change the array type to integer then the following error occurs,

M_06inz.c: In function 'M_eqFunction_3':
M_06inz.c:64: error: incompatible type for argument 1 of 'sub_alloc_integer_array'
C:/OpenModelica/trunk/build//include/omc/c/util/integer_array.h:183: note: expected 'const struct integer_array_t *' but argument is of type 'integer_array'
M_06inz.c:64: error: incompatible type for argument 2 of 'sub_alloc_integer_array'
C:/OpenModelica/trunk/build//include/omc/c/util/integer_array.h:183: note: expected 'const struct integer_array_t *' but argument is of type 'integer_array'
M_06inz.c:64: error: too few arguments to function 'sub_alloc_integer_array'

[Adeel Asghar]

Replying to adeas31:

I tested the same model with real array and it worked fine. But if we change the array type to integer then the following error occurs,

M_06inz.c: In function 'M_eqFunction_3':
M_06inz.c:64: error: incompatible type for argument 1 of 'sub_alloc_integer_array'
C:/OpenModelica/trunk/build//include/omc/c/util/integer_array.h:183: note: expected 'const struct integer_array_t *' but argument is of type 'integer_array'
M_06inz.c:64: error: incompatible type for argument 2 of 'sub_alloc_integer_array'
C:/OpenModelica/trunk/build//include/omc/c/util/integer_array.h:183: note: expected 'const struct integer_array_t *' but argument is of type 'integer_array'
M_06inz.c:64: error: too few arguments to function 'sub_alloc_integer_array'

r23726 should fix the above error.

[Henning Kiel]

Adeel, r23726 does *not* fix the problem, as you create the returned object on the stack which is likely to be destroyed when you use it!

Anyway, why do you return the array object? All other functions have a "integer_array_t * dest" pointer as parameter for this. Maybe we need to fix CodegenC.tpl to use correct signature of that function?

[Martin Sjölund]

All functions that use alloc should be possible to return directly. The array is just a struct, and the data inside the struct is heap-allocated.
For the non-alloc functions, we take a dest and write to the old data locations.

The alloc functions should be used when temporary arrays are needed, but the code generation uses them more often than necessary (because the intermediate representation is poor).

[Henning Kiel]

OK. So, the fixed function seems to work.

I still see lots of *_alloc_* functions (in integer_array.c) that have different parameter scheme than sub_alloc_* function.

And also one in real_array.c: void cross_alloc_real_array(const real_array_t * x,const real_array_t * y, real_array_t* dest);

Shall those be adjusted, too?

[Adeel Asghar]

Replying to hkiel:

OK. So, the fixed function seems to work.

I still see lots of *_alloc_* functions (in integer_array.c) that have different parameter scheme than sub_alloc_* function.

And also one in real_array.c: void cross_alloc_real_array(const real_array_t * x,const real_array_t * y, real_array_t* dest);

Shall those be adjusted, too?

Yes.

[Adeel Asghar]

r23733 should fix Boolean assignment issue.
I am not sure if the fix is done in the correct way but my tests seems to work fine.

[Lennart Ochel]

Yes, it seem to work with your changes. I close this ticket as long as no one complains.

[Lennart Ochel]

BTW: Should we put the example to the testsuite or is it already tested by other ones?

[Adeel Asghar]

I have a similar example in the testsuite already.
​https://openmodelica.org/svn/OpenModelica/trunk/testsuite/openmodelica/fmi/ModelExchange/2.0/BooleanNetwork1.mos

[Dietmar Winkler]

It doesn't make sense to keep closed ticket in the "Future" milestone that were simply forgotten to assign to the correct milestone in the past.

[Martin Sjölund]

Removing the pre1.9.4 milestone in favor of 1.9.4.