0

I have what looks to me an innocent cycle which iterates on elements of an array whose type is unknown at compile time; my array is named mesh->vertices and is a pointer to void. Depending on the truth value of mesh->textured I need to consider the array differently. Incidentally, the code in the if and the else in the code segment below is similar, but I do need to distinguish two cases.

void TransformMesh(struct Mesh *mesh, struct Matrix4 *t)
{
    for (int i = 0; i < mesh->nVertices; ++i)
    {
        if (mesh->textured)
        {
            struct TexturedVertex *ptr = ((struct TexturedVertex *)mesh->vertices) + i;

            ptr[i].position = MatrixPointMultiply3(t, &ptr->position);
            ptr[i].normal = MatrixPointMultiply3(t, &ptr->normal);
        }
        else
        {
            struct Vertex *ptr = ((struct Vertex *)mesh->vertices) + i;

            ptr[i].position = MatrixPointMultiply3(t, &ptr->position);
            ptr[i].normal = MatrixPointMultiply3(t, &ptr->normal);
        }
    }
}

I guess I created the project with the Automatic Reference Counting option, thinking that it would not have affected C code, but now I feel like I'm wrong (by the way, how can I check which option I chose?).

Well, it looks like this function is doing something wrong with another array, called mesh->triangles, probably freeing it. When I try to use the vector I get an EXC_BAD_ACCESS error:

glDrawElements(GL_TRIANGLES, mesh->nTriangles * 3, GL_UNSIGNED_INT, mesh->triangles);

It looks like iterating on the mesh->vertices elements, casting them and doing the pointer arithmetic, is corrupting the memory. I think my problem is ARC, so I tried to do what described here but with no luck.

EDIT:

The code above was wrong, as pointed out by Conrad Shultz; the following is correct:

            ptr->position = MatrixPointMultiply3(t, &ptr->position);
            ptr->normal = MatrixPointMultiply3(t, &ptr->normal);
Community
  • 1
  • 1
damix911
  • 4,165
  • 1
  • 29
  • 44
  • 2
    ARC only affects Objective-C objects. I'm not sure what the issue with this code is, but it's not ARC. – zpasternack Aug 03 '12 at 00:54
  • Thank you zpasternak, that was my initial conjecture but then I began to doubt. I'm happy to hear that C part is really C. – damix911 Aug 03 '12 at 10:17

1 Answers1

2

I seriously doubt ARC has anything to do with this - ARC only manages Objective-C objects. (It doesn't even know how to handle Core Foundation types, which leads to the requirement for using the __bridge... keywords.)

I'm struggling to understand your code. Admittedly, I don't do a great deal of straight C programming, but I don't get what you're trying to do by adding i to ptr, which is presumably the pointer arithmetic of which you speak.

Are you trying to just access the ith struct TexturedVertex in mesh->vertices? If so, just use your ptr[i] construct as written.

It looks to me like you are doing arithmetic such that ptr ends up pointing to the ith struct TexturedVertex, then by accessing ptr[i] you are reading i elements past the ith struct TexturedVertex. If nVertices refers to the count of vertices (as would seem logical, given the name and C array conventions), you are then reading past the end of vertices, a classic buffer overflow error, which would unsurprisingly lead to EXC_BAD_ACCESS and all sorts of other fun errors.

Conrad Shultz
  • 8,748
  • 2
  • 31
  • 33
  • Conrad Schultz you are uber-right, I changed a few times between the ptr[i] style and the ptr + i style because i was getting a weird behaviour from the iPad (black screen, I don't know why) and in the end the code ended up doing the same thing two times, that is I was actually accessing 2*nVertices elements. When I switched to the emulator I saw the EXC_BAD_ACCESS error, but the weird thing is that it was not raised in my "wrong" function, but somewhere else later in the code. Now however everything is working fine, thank you. – damix911 Aug 03 '12 at 01:09
  • @damix911 Glad you got it working. That's the nasty thing about memory bugs - you will often get *something* off the end of the array, and the compiler will happily cast it to what you thought it is. Sometime down the road, you use that bogus data and everything blows up. They're tricky, those pointers. – Conrad Shultz Aug 03 '12 at 01:17