Excellent catch, Hamlet! I went back and looked through some old compiler output logs and that warning has been there all along and I never saw it because, in further support of your point, one simply cannot easily see the critically important compiler warnings because they're buried in so much noise!
I'm a bit embarrassed that I missed this serious warning. I was intending to start looking into all those warnings at some point, once the 2.05-beta issues (and some other issues) are fully addressed. Given the presence of such a bug that the compiler was screaming at me about, only for me to ignore it, I'm thinking that I should accelerate that task a bit, at least to the extent that I'm not "stepping on your toes" or otherwise interfering.
Grayman, I sympathize with your position and viewpoint, but only up to a point. I think this is an excellent example of why we need to at least begin to address all (and hopefully, eventually, eliminate as many) of these warnings as we possibly can.
It sounds like in this case, the GCC compiler is more capable than the Windows compiler, even though this bug (and make no mistake, this is a bug!) affects all OSes. I have a feeling that, overall, the GCC compiler may be much more thorough than the Windows compiler, but I have no hard evidence for this, only my experience over many years of the GCC suite getting better and better at finding problems in my (and others') code. If the Windows compiler has the equivalent of the GCC compiler options "-Wall" ("enables all the warnings about constructions that some users consider questionable") and/or "-Wextra" ("enables some extra warning flags that are not enabled by -Wall"), then it might be wise to enable them (assuming they aren't already), to see what folks compiling under Windows may have been missing for a while. In fact, I'd ask anyone compiling TDM under Windows (duzenko, maybe?) to check: Did it warn about this particular "memset()" call?
I wanted to have a bit more hard evidence for my position about fixing warnings, so I added a couple of lines to 'Model_ase.cpp' on the 2.05-beta build, compiled it, ran TDM, and loaded up the "Flakebridge Monastery" mission (simply because that's what I last used in my "Baal crash" testing). I found that the structure being zeroed is a 96-byte structure, but with the bug, it's only clearing 4 of the 96 bytes. And, more importantly, just loading (not even playing) the mission, that routine is called 547 times, with that particular erroneous 'memset()' call happening a whopping 80 times! Now maybe it turns out to be harmless -- this part of the code is about "meshes" and "animation" and I'm not smart enough on modeling to understand the real effect of this bug, but it clearly needs to be fixed. On that, I am unbending.
BTW, this bug is in the original Doom3 engine's code.
I'd encourage a "middle ground" here. Let's fix these warnings, but slowly and carefully (not that Hamlet was suggesting otherwise).
Hamlet, as you know, I'm very grateful to have another Linux builder commenting and contributing, especially one with your skill level, especially in C++, however frequently you might be inclined to post here. I'm of the same mindset as you are and I'd like to improve TDM as much as reasonably possible, over the course of the next several weeks or months, as time is available.
Grayman, I hope you'll agree that there is inherent merit to addressing these warnings, without always having to "point to the bug as the player experiences it before changing anything". In all of my myriad projects, all compiled with GCC, I generally don't ever allow any warnings in a build, frequently even enforcing that with the "-Werror" ("Make all warnings into errors.") GCC compiler option.
Warnings are often pointing out a very nasty, sometimes insidious bug. I've seen far too many projects casually ignore compiler warnings. Please, let's not be one of them, at least not in the long run.
As for fixing bugs before warnings, I don't disagree a bit, but I've scanned the BugTracker and don't see anything that I am capable of addressing. So my plan is to publish the info (later today, I hope) about Baal's crash and then start looking into an oddity (possible bug) in the "latest SVN" build for which I have not had time to confirm if it's also in 2.05-beta. If there are other open bugs within my grasp that I'm unaware of, definitely, please, let me know.
Finally, can anyone who understands animations and meshes comment: what might the effect be of not fully clearing (zeroing) out a "mesh" in code with the brief comment "ignore regular meshes that aren't part of animation"?