[Unifex] Nested list type iterator redefinition causes segmentation fault

[veliandev]

In the file lib/unifex/code_generator/base_types/list.ex, there is an issue regarding the way we iterate over list types. As we can see on line 37 for example, we have this definition of:
for(unsigned int i = 0; i < #{name}_length; i++) {

The memory risk of this isn't a big deal on it's own, but the moment we nest a list within this list type our C or C++ will redefine the iterator as i the next layer down. I fixed this on a fork but it's a really crappy hack fix I wrote for my own use. The fix is as follows:

for(unsigned int #{ctx.subtype}_iter = 0; #{ctx.subtype}_iter < #{name}_length; #{ctx.subtype}_iter++) {

This will allow us to be able to nest lists in lists in lists, unless we define a list1 that has a list2 that references a list1; that'll probably cause some headaches. There's a lot of definitions of for loops that generate nested types that do not consider that they will redefine the iterator, so I hope this can be looked at by someone who knows what they are doing and not someone like me who hacks it just to get it functioning.

For reference, my testing types were as follows:

spec load_model_animations(filename :: string) :: result :: [model_animation]

type bone_info :: %Rayex.Structs.BoneInfo{
       name: string,
       parent: int
     }
     
type model_animation :: %Rayex.Structs.ModelAnimation{
        bone_count: int,
        frame_count: int,
        bones: [bone_info], # <---- This guy would redefine the iterator, bricking the return function with a segfault
        name: string
     }

[bartkrak]

@veliandev Are you using nif or cnode? We have a fix for nif, but there are some additional problems with cnode. If you don't need cnode, we wouldn't need to fix it right now.

[veliandev]

Just NIF currently, but I compile with both NIF and CNODE flags to give end users options. If it takes a while longer, no stress; as long as the NIFs are sorted that should be enough to start moving.

[bartkrak]

@veliandev cNode is also ready