Next semester, I'll be making a game in C (C89 specifically). Coming from higher-level languages such as C#, one of the first things I would do is make a List of Entities (game objects), and every frame, loop through each Entity and run their Update and Draw methods. Converting this ideology to C, my idea was to develop a "List" structure that contains a pointer to an array of void pointers, and making functions to add, get, and remove entries from the list. If an object is added to the List but the array is too small, realloc the array to a twice-as-large array. With this system in place, when I, say, spawn an enemy, I can add a pointer to its Entity struct to the List, and then each frame, loop through the List, cast each void pointer element as a pointer to an Entity, and then pass it to entity_update(Entity *) and entity_draw(Entity *) methods accordingly.
In my mind, as long as I'm 100% sure to only put pointers to Entity structs (cast as void pointers) in the List array, there wouldn't be any problem... but when I mentioned this to a classmate, he said that he thought there were performance drawbacks associated with casting void pointers to pointers to other things. Looking around on the Internet, from what I can tell, the real problem is that compilers can't properly optimize your code as they would if the compiler knew in advance what type the pointer pointed to. Would this end up being a problem in my situation, where I want to loop through a potentially large-ish array of void pointers, sixty times a second? It wouldn't be a huge deal to just store pointers to Entities in an array of Entity pointers, with a large, predefined maximum size, and then do bound checking to make sure i.e. an enemy isn't spawned if there's no room left in the array... but I just wanted to make sure before I started working on the basic underlying engine stuff for the game.
In C casting a pointer doesn't actually do anything except tell the compiler to treat it as a different type. There's no runtime overhead.
So no.