cdecl proc mistakenly gets a pointer in generated C code (FFI, no bycopy)

[oprypin]

type Vertex = object
    position: Vector2f
    color: Color
    texCoords: Vector2f

type VertexArray = ptr object

proc append(vertexArray: VertexArray, vertex: Vertex) {.
  cdecl, dynlib: "libcsfml-graphics.so", importc: "sfVertexArray_append".}

Dl_106214 = (TY106215) nimGetProcAddr(TMP163, "sfVertexArray_append");

typedef N_CDECL_PTR(void, TY106215) (vertexarrayHEX3Aobjecttype104444* vertexarray, 
                                     vertex105041* vertex);

---

triangle.append v1  # triangle is a VertexArray, v1 is a Vertex

Dl_106214(triangle_110022, (&v1_110028));

---

As you can see, the function signature in generated C code has the 2nd argument as a pointer, while Vertex is a normal object. As I've been told, this may be caused by a lack of {.bycopy.} on Vertex; Nim decides it wants to pass such a big object by a pointer. But it is unacceptable to modify the signature of a function if it is part of C FFI.

It was extremely hard to track down the problem, because the code compiled and worked without crashing, just wrote pointers where data was expected...

[Araq]

But it is unacceptable to modify the signature of a function if it is part of C FFI.

Er no? But ok, what makes it part of the C FFI? 'cdecl'? Hardly. 'dynlib'? What if it's dynlib imported from Nim?

[Araq]

Well we cannot change the FFI at this point, the breaking change would be enormous and it's not a bug but documented behaviour.