4 ms·

> I'm constantly amazed by the perversity of 'compliant' compilers, but can this be true? V597 - http://www.viva64.com/en/d/0208/ http://www.viva64.com/en/d/02

> I'm constantly amazed by the perversity of 'compliant' compilers, but can this be true? V597 - http://www.viva64.com/en/d/0208/ http://www.viva64.com/en/d/0208/ Zero and forget -- caveats of zeroing memory in C - http://www.eliteraspberries.com/blog/2012/10/zero-and-forget--caveats-of-zeroing-memory-in-c.html http://www.eliteraspberries.com/blog/2012/10/zero-and-forget... Overwriting memory - why? - http://www.viva64.com/en/k/0041/ http://www.viva64.com/en/k/0041/

nkurz 13y ago
I think I understand those issues, and I agree that this is potentially a real bug. It's the statements in your description I'm not sure I agree with. I do not believe though that a compiler is allowed to remove a function call to the external library function call memset(), as it does not know whether there are any side effects to that call. It does not matter if I use the argument again afterward, a library function call will not be optimized out. Consider: what if at runtime I link to a different library where memset() performs IO? The issue is that there is that there may be no function call to the library function memset() in the source. Rather, memset() may be defined as a macro such that the memory manipulations are inlined. Since the optimizer sees only these memory operations (rather than the function call), in the absence of a 'volatile' declaration it can legally delete them. Thus whether this is actually a bug depends on whether the compiler treats memset() as a builtin macro. This is only a bug if there is no function call in the source by the time the preprocessor has done its work. One does not have to live in fear that a compliant compiler will delete non-local function calls. Or at least if it does, it's a bug in the compiler.