blocks|key|3371957|text|在释放内存块时将其清零需要额外的时间。由于大多数情况下实际上不需要这样做，所以默认情况下不会这样做。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3371958|如果您确实需要(假设您使用内存来存储密码或密钥)-在释放块之前调用memset()。编写一个链接memset()和free()的实用函数也不是问题。|offset|length|style|CODE|3371959|entityMap^0|0|X|8|1C|8|1L|6|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]|$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|I|$]]

Zeroing out the memory block when freeing it will require extra time. Since most of time there's actually no need in it it is not done by default.

If you really need (say you used memory for storing a password or a cryptographic key) - call <code>memset()</code> before freeing the block. Writing an utility function that chains <code>memset()</code> and <code>free()</code> is not a problem either.

blocks|key|2306044|text|free()不会将内存释放回OS+-它会释放回进程的堆管理器。出于效率的原因，它不是零。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2306045|当一个进程分配虚拟内存时，大多数操作系统都会给它一个零页。这可以防止内存从一个进程“泄漏”到另一个进程，并导致您提到的安全问题。|2306046|如果您的进程中有不想保存在内存中的数据(例如，用户的密码)，您需要负责将其清零。Windows为此提供了SecureZeroMemory应用程序接口。|2306047|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

free() doesn't release memory back to the OS - it releases back to the process's heap manager. For efficiency reasons, it is not zero'd out.

When a process allocates virtual memory, most OS's will hand it a zero'd page. This prevents memory from "leaking" from one process to the other and causing a security issue like you mention.

If you have data in your process that you don't want to keep in memory (for example, a user's password), you are responsible for zeroing it out. Windows provides the SecureZeroMemory API for this.

blocks|key|2300962|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2300963|+C为什么在空闲实现中内存没有明确设置为零。|blockquote|2300964|2300965|2300966|因为速度的原因。|2300967|2300968|，因为在我们释放内存之后，我们如何在释放后将它设置为零。|2300969|2300970|2300971|嗯？|2300972|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|Q|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|R|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|S|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|T|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|U|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|V|7|@]|8|@]|9|$]]|$1|I|3|J|4|C|6|W|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|X|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|Y|7|@]|8|@]|9|$]]|$1|M|3|N|4|5|6|Z|7|@]|8|@]|9|$]]|$1|O|3|-4|4|5|6|10|7|@]|8|@]|9|$]]]|P|$]]

<blockquote>
 C why is the memory not explictly set to zero in the free implementation . 
</blockquote>

Because of speed. 

<blockquote>
 Because after we free the memory any how we set it to zero after freeing.
</blockquote>

Eh?

blocks|key|2301027|text|如果您希望在释放内存时将其设置为0，则必须在使用free()之前自己执行此操作。如果你在free()它之后尝试，就不能保证它不会被再次分配。例如，您可以使用memset()来实现此目的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2301028|free()不保证内存将被清除，因为C不保证malloc()将返回初始化的内存。无论哪种方式，你都必须在它被分配之后自己初始化它，所以当它是free()'d时，清除它是没有意义的|2301029|entityMap|0|LINK|mutability|MUTABLE|url|http://www.manpagez.com/man/3/memset/^0|O|6|18|6|26|8|26|8|0|0|0|6|M|8|1Y|6|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@$9|W|A|X|1|Y]]|E|$]]|$1|F|3|G|5|6|7|Z|8|@$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

If you want the memory to be set to 0 when you free it, you'll have to do it yourself before you <code>free()</code> it. If you try after you <code>free()</code> it there are no guarantees that it hasn't been allocated again. For instance you can use <a href="http://www.manpagez.com/man/3/memset/" rel="noreferrer"><code>memset()</code></a> for that.

<code>free()</code> doesn't guarantee that the memory will be cleared because C doesn't guarantee that <code>malloc()</code> will return initialized memory. Either way you have to initialize it yourself after it's been allocated, so there's no point in clearing it when it's <code>free()</code>'d

blocks|key|2301052|text|编辑:这是一个尝试回答原始发帖的问题。这个问题可能被shog9的编辑改变了，也可能没有改变--很难说，因为原文并不清楚……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2301053|如果您的意思是，像其他人假设的那样，为释放的内存块的每个字节设置0，那么在释放内存块之后就不能这样做了。尝试这样做会产生未定义的行为。因此，如果您这样做，那么您严重误解了内存分配。|2301054|但我猜，当你说“释放后我们将其设置为零”时，你可能在谈论这样的代码：|2301055|free(ptr);
ptr+=+NULL;|code-block|syntax|javascript|2301056|如果是这样，那么free不能将ptr设置为NULL的原因是free只接收来自变量ptr的值。它无法修改ptr，因为您没有将变量ptr本身传递给free。您只是在传递当前存储在其中的地址。这是C语言设计的一部分-当你调用一个传递一个值的函数时，被调用者就无法知道这个值是如何计算出来的，也无法知道调用者的代码中可能包含这个值的变量。即使这是可能的，但仅仅免费地为这一语言规则创建例外将是疯狂的。|2301057|在任何情况下，并不是每个人都在释放指针后将它们清零。一些人认为这是一个很好的安全措施，另一些人认为它不是。然而，不管你怎么想，代码并没有将内存置零，它只是将指向内存的指针置零。如果您想要编写一个函数来清除指针，那么您可以：|2301058|void+free_and_clear(void+**pptr)+{
++++free(*pptr);
++++*pptr+=+NULL;
}|2301059|然后像这样使用它：|2301060|free_and_clear(&ptr);|2301061|请注意，这将传递一个指向变量ptr的指针，而不是ptr的值。因此，free_and_clear可以修改ptr。但这对你如何使用它有一些限制，这不适用于free+-你需要一个指向一个可修改的值的指针，而不仅仅是一个值。|2301062|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|11|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|H|7|14|8|@]|9|@]|A|$I|J]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|H|7|16|8|@]|9|@]|A|$I|J]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

[Edit: this is an attempt to answer the original poster's question. The question may or may not have been changed by shog9's edit - it's hard to say since the original was unclear...]

If you mean, as others have assumed, setting 0 for every byte of the memory block being freed, then you cannot do that after freeing the block. Attempting to do it yields undefined behaviour. So if you're doing that, then you have badly misunderstood memory allocation.

But I'm guessing when you say "we set it to zero after freeing", you're maybe talking about code like this:

<pre><code>free(ptr);
ptr = NULL;
</code></pre>

If so, then the reason free can't set ptr to NULL, is that free only receives the value from the variable ptr. It has no way of modifying ptr, because you aren't passing the variable ptr itself into free. You're just passing the address currently stored in it. This is part of the design of the C language - when you call a function passing a value, then the callee cannot tell how that value was computed, or what variable might contain it in the caller's code. Making an exception to this language rule just for free would be crazy, even if it were possible.

In any case, not everyone zeroes out pointers after freeing them. Some people think it's a good safety measure, other people think it is not. Whatever you think of it, though, the code doesn't zero the memory, it only zeros the pointer to the memory. If you want to write a function which clears the pointer for you, then you can:

<pre><code>void free_and_clear(void **pptr) {
 free(*pptr);
 *pptr = NULL;
}
</code></pre>

Then use it like this:

<pre><code>free_and_clear(&amp;ptr);
</code></pre>

Note that this passes a pointer to the variable ptr, instead of the value of ptr. So free_and_clear can modify ptr. But this puts some restrictions on how you can use it which don't apply to free - you need a pointer to a modifiable value, rather than just a value.

blocks|key|394115|text|最初的C哲学是将隐含的影响保持在绝对最小。如果程序员想要一个指针在指向的内存被释放后置零，这就是程序员应该写的。我们这些经常使用这样的宏的人：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|394116|#define+FREE(P)+((void)(free((P)),+(P)+=+NULL))|code-block|syntax|javascript|394117|当然，如果传递给FREE的表达式有副作用，那就是打开了一个巨大的蠕虫罐头……|CODE|394118|entityMap^0|L|Z|0|0|8|4|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|S|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|T|8|@$9|U|A|V|B|M]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|O|$]]

The original C philosophy was to have keep implicit effects to an absolute minimum. If a programmer wants a pointer zeroed after the memory pointed to is freed, that's what the programmer should write. Those of us who do often use a macro like this one:

<pre><code>#define FREE(P) ((void)(free((P)), (P) = NULL))
</code></pre>

Of course if the expression passed to <code>FREE</code> has side effects, one has just opened a large can of worms...

blocks|key|2305876|text|memset(ptr,+0,+size);
free(ptr);|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|2305877|我觉得你想要这个..。|unstyled|2305878|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|J|8|@]|9|@]|A|$]]|$1|G|3|-4|5|F|7|K|8|@]|9|@]|A|$]]]|H|$]]

<pre><code>memset(ptr, 0, size);
free(ptr);
</code></pre>

i think you want this...

blocks|key|5483528|text|C最初被设计为一种系统实现语言，因此C操作通常尽可能快，尽可能接近实际。设计哲学中的一个关键点是，您可以采用几个快速操作，并将它们转换为一个更慢、更安全的操作，但您不能采用更慢、更安全的操作，而进行更快的操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5483529|如果你想要一个零和自由的函数，你可以写一个，然后用它来代替free()。如果您关心安全性，我建议您使用它。|offset|length|style|CODE|5483530|entityMap^0|0|T|6|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

C was originally designed as a system implementation language, and so C operations are generally as fast and as close to the metal as is practical. One key point in the design philosophy is that you can take several fast operations and make them into one slower and safer operation, but you can't take slower and safer operations and make a faster one.

If you want a zero-and-free function, you can write one, and use it instead of <code>free()</code>. If you're concerned with security, I'd recommend it.

blocks|key|2301074|text|对“为什么释放内存后没有设置为0？”这一问题给出了非常具体的答案。是“，因为语言规范没有定义该行为。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2301075|从ANSI规范草案中可以看出：“free函数使ptr指向的空间被释放，即可用于进一步的分配。”|2301076|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

A very specific answer to the question "Why is the memory not set to 0 after freeing it?" is "Because the language specification does not define that behavior.

From the draft ANSI C spec: "The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation."

blocks|key|394041|text|将释放的指针的结果设置为零似乎是胡说八道，但如果后来无意中访问了该指针，您将得到一个段错误(至少在真正的操作系统中是这样)，并且调试器将指向发生这种令人厌恶的情况的位置。但正如其他人所指出的那样，当您稍后调用"+free“时，所有的free都是free的地址，没有其他内容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|394042|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Setting the result of a freed pointer to zero may seem to be bullshit, but if the pointer is inadvertently accessed later, you'll get a segfault (at least in a real OS), and the debugger will point to where this abomination is happening. But as others have noted, when you call "free" later, all free has is the address to free, and nothing else.

blocks|key|5483430|text|如果我正确理解了这个问题，行动人员不希望将敏感信息留在“那里”，因为他们担心这些信息会被泄露。正如前面的帖子所指出的，在释放内存之前释放内存是擦除数据的答案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5483431|然而，这远不是OP试图实现的目标的答案。对于初学者来说，清零内存在保护应用程序方面是100%25无用的。即使内存页面被分配给另一个正在运行的进程，在大多数操作系统中，这个过程也是不确定的，任何理智的黑客都不会使用这样的技术来危害你的数据。|5483432|一个理智的黑客会做的就是把你的程序放到一个反汇编程序中，通过它进行调试，直到他们找出数据在哪里，然后再使用它。因为一旦你是一个称职的反汇编程序(是的，反汇编程序:)，对memset的调用就非常明显了)，我们假设的黑客只会在memset发生之前获取数据。|5483433|来真正回答你的问题。如果你试图保护C程序中的一些敏感数据，你就进入了远远超出正常C/C%2B%2B程序员(像我自己)的领域，进入了编写虚拟机来执行数据敏感操作的领域。|5483434|你甚至问了这个问题，这就意味着你开发需要这种级别保护的东西是不计后果的。此外，它绝对不会是保护您的数据的第一站。首先选择低垂的水果，网络上有很多关于这方面的信息。|5483435|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

If I understand the question correctly the OP wants to not leave sensitive information "out there" in fear of it being compromised. As the previous posters pointed out freeing the memory before releasing it is the answer to wiping the data.

However, it is far from the answer to what the OP is trying to achieve. For starters zeroing the memory is 100% useless in securing your application. Even if the memory page is allocated to another running process, in most OSs this procedure is non-deterministic and no sane hacker will EVER use such a technique to compromise your data.

What a sane hacker would do is whack your program into a disassembler and debug through it until they figure out where the data is and then use it. Since a call to memset is bleedingly obvious once you are a competent disassemblerator(yes, disassemblerator :) ) our hypothetical hacker would just get to the data before memset happens.

To really answer your question. If you are trying to protect some sensitive data inside your C program you are getting in the domain that is far beyond normal C/C++ programmers(like myself) into realm of writing virtual machines for executing your data sensitive operations. 

The fact that you even ask this question means that it would be reckless for you to develop something that requires this level of protection. Also it will absolutely not be the first stop in protecting your data. Pick the low hanging fruit first and there is plenty info on the web about that.

blocks|key|3371908|text|因为这纯粹是浪费时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3371909|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Because it would be a pure waste of time.

blocks|key|2305929|text|一旦使用free()释放内存，该值&分配给该特定地址的内存将被删除(释放)，但指针仍然指向该地址。如果您尝试取消引用该指针，则会出现分段错误或总线错误。因此，一旦指针指向的内存被释放，将NULL值赋给指针是安全的。你可以参考<+Setting+variable+to+NULL+after+free+>|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2305930|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1025589/setting-variable-to-null-after-free^0|36|Z|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Once you free memory using free(), the value &amp; the memory allocated at that particular address gets deleted (freed) but the pointer still points to that address. If you try to de-reference that pointer you will get Segmentation fault or Bus error. So, its safe to assign NULL value to the pointer once the memory pointed by the pointer is freed. You may refer &lt; <a href="https://stackoverflow.com/questions/1025589/setting-variable-to-null-after-free">Setting variable to NULL after free</a> >

blocks|key|5483494|text|还有bzero(3)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5483495|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

blocks|key|394201|text|“当我们在C中释放()内存时，为什么那个内存没有被填满呢？”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|394202|一般来说，不需要在释放时将每个释放的内存块都清零，这样编译器就可以生成更好的代码。|394203|“在调用free()时，有没有一种好的方法来确保这是理所当然的？”|394204|不怎么有意思。有许多尝试来解决死存储消除，但它们都存在合规性或可移植性问题。|394205|此演示文稿很好地总结了这一细微差别的问题，并提供了指向其解决方案源代码的链接，此处转载了该链接。|394206|https://www.usenix.org/sites/default/files/conference/protected-files/usenixsecurity17_slides_zhaomo_yang.pdf|offset|length|394207|//+secure_memzero.h+version+1+(October+29,+2016)
//+
//+This+code+is+released+into+the+public+domain.
//
//+THIS+SOFTWARE+IS+PROVIDED+"AS+IS"+AND+ANY+EXPRESS+OR+IMPLIED+WARRANTIES,
//+INCLUDING,+BUT+NOT+LIMITED+TO,+THE+IMPLIED+WARRANTIES+OF+MERCHANTABILITY+AND
//+FITNESS+FOR+A+PARTICULAR+PURPOSE+ARE+DISCLAIMED.+IN+NO+EVENT+SHALL+THE
//+AUTHORS+BE+LIABLE+FOR+ANY+DIRECT,+INDIRECT,+INCIDENTAL,+SPECIAL,+EXEMPLARY,
//+OR+CONSEQUENTIAL+DAMAGES+(INCLUDING,+BUT+NOT+LIMITED+TO,+PROCUREMENT+OF
//+SUBSTITUTE+GOODS+OR+SERVICES;+LOSS+OF+USE,+DATA,+OR+PROFITS;+OR+BUSINESS
//+INTERRUPTION)+HOWEVER+CAUSED+AND+ON+ANY+THEORY+OF+LIABILITY,+WHETHER+IN
//+CONTRACT,+STRICT+LIABILITY,+OR+TORT+(INCLUDING+NEGLIGENCE+OR+OTHERWISE)
//+ARISING+IN+ANY+WAY+OUT+OF+THE+USE+OF+THIS+SOFTWARE,+EVEN+IF+ADVISED+OF+THE
//+POSSIBILITY+OF+SUCH+DAMAGE.

//+The+secure_memzero+macro/function+attempts+to+ensure+that+an+optimizing
//+compiler+does+not+remove+the+intended+operation+if+cleared+memory+is+not
//+accessed+again+by+the+program.+There+are+several+known+ways+of+doing+this,
//+however+no+single+one+is+both+universally+available+and+absolutely+guranteed
//+by+the+standard.+The+following+code+defines+secure_memzero+as+a+macro+or
//+function+using+one+of+the+known+alternatives.+The+choice+of+implementation
//+can+be+controlled+by+defining+a+preprocessor+macro+of+the+form+SMZ_impl,
//+where+<impl>+is+one+of+the+defined+implementation+names.+SMZ_impl+should
//+expand+to+an+integer+indicating+the+dgeree+of+preference+for+the
//+implementation,+where+numerically+higher+values+indicate+greater+preference.
//+Defining+SMZ_impl+to+be+0+disables+the+implementation+even+if+it+is
//+available.+Not+defining+any+SMZ_impl+will+result+in+default+(safe)+behavior.
//+
//+The+following+implementations+may+be+used.
//+
//+SMZ_SECUREZEROMEMORY
//+Uses+the+SecureZeroMemory+macro/function+on+Windows.+Requires+a+Windows
//+environment+(_WIN32+must+be+defined).
//+
//+SMZ_ASM_BARRIER
//+Uses+a+compiler+memory+barrier+to+force+the+results+of+a+memset+to+be
//+committed+to+memory.+Has+been+tested+to+work+on:
//+-+Clang+3.9.0+at+all+optimization+levels.
//+-+GCC+6.2+at+all+optimization+levels.
//+
//+SMZ_MEMSET_S
//+Uses+the+C11+function+memset_s.+Currently+not+available+on+many+platforms.
//+Note+that+if+you+want+this+option,+you+have+to+set+__STDC_WANT_LIB_EXT1__
//+to+1+before+including+string.h+or+any+file+that+includes+string.h+in+a
//+compilation+unit+that+includes+this+header.
//+
//+SMZ_VDATAPTR
//+Uses+the+volatile+data+pointer+technique+to+zero+one+byte+at+a+time.+This+is
//+not+guaranteed+to+work+by+the+C+standard,+which+does+not+require+access+to
//+non-volatile+objects+via+a+pointer-to-volatile+to+be+treated+as+a+volatile
//+access.+However,+it+is+known+to+work+on+the+following+compilers:
//+-+Clang+3.9.0+at+all+optimization+levels.
//+-+GCC+6.2+at+all+optimization+levels.
//+
//+SMZ_VFUNCPTR
//+Uses+the+volatile+function+pointer+technique+to+call+memset.+This+is+not
//+guaranteed+to+work+by+the+C+standard,+which+does+not+require+the+pointed-to
//+function+to+be+called.+However,+it+is+known+to+work+on+the+following
//+compilers:
//+-+Clang+3.9.0+at+all+optimization+levels.
//+-+GCC+6.2+at+all+optimization+levels.

//+The+remainder+of+this+file+implements+the+selection+logic+using+the
//+specified+compile-time+preferences.

#ifndef+_SECURE_MEMZERO_H_
#define+_SECURE_MEMZERO_H_

//+STEP+1.+Set+default+preference+for+all+implementations+to+1.

#ifndef+SMZ_SECUREZEROMEMORY
#define+SMZ_SECUREZEROMEMORY+1
#endif

#ifndef+SMZ_MEMSET_S
#define+SMZ_MEMSET_S+1
#endif

#ifndef+SMZ_ASM_BARRIER
#define+SMZ_ASM_BARRIER+1
#endif

#ifndef+SMZ_VDATAPTR
#define+SMZ_VDATAPTR+1
#endif

#ifndef+SMZ_VFUNCPTR
#define+SMZ_VFUNCPTR+1
#endif

//+STEP+2.+Check+which+implementations+are+available+and+include+any+necessary
//+header+files.

#if+SMZ_SECUREZEROMEMORY+>+0
#ifdef+_WIN32
#include+<windows.h>
#else
#undef+SMZ_SECUREZEROMEMORY
#define+SMZ_SECUREZEROMEMORY+0
#endif
#endif

#if+SMZ_MEMSET_S+>+0
#if+defined(__STDC_WANT_LIB_EXT1__)+&&+(__STDC_WANT_LIB_EXT1__+!=+1)
#undef+SMZ_MEMSET_S
#define+SMZ_MEMSET_S+0
#endif
#if+SMZ_MEMSET_S+>+0
#ifndef+__STDC_WANT_LIB_EXT1__
//+Must+come+before+first+include+of+string.h
#define+__STDC_WANT_LIB_EXT1__+1
#endif
#include+<string.h>
#ifndef+__STDC_LIB_EXT1__
#undef+SMZ_MEMSET_S
#define+SMZ_MEMSET_S+0
#endif
#endif
#endif

#if+!defined(__GNUC__)+&&+!defined(__clang__)
#undef+SMZ_ASM_BARRIER
#define+SMZ_ASM_BARRIER+0
#endif

#if+SMZ_VFUNCPTR+>+0
#include+<string.h>
#endif

//+STEP+3.+Calculate+highest+preference.

#define+SMZ_PREFERENCE+0

#if+SMZ_PREFERENCE+<+SMZ_SECUREZEROMEMORY
#undef+SMZ_PREFERENCE
#define+SMZ_PREFERENCE+SMZ_SECUREZEROMEMORY
#endif

#if+SMZ_PREFERENCE+<+SMZ_MEMSET_S
#undef+SMZ_PREFERENCE
#define+SMZ_PREFERENCE+SMZ_MEMSET_S
#endif

#if+SMZ_PREFERENCE+<+SMZ_ASM_BARRIER
#undef+SMZ_PREFERENCE
#define+SMZ_PREFERENCE+SMZ_ASM_BARRIER
#endif

#if+SMZ_PREFERENCE+<+SMZ_VDATAPTR
#undef+SMZ_PREFERENCE
#define+SMZ_PREFERENCE+SMZ_VDATAPTR
#endif

#if+SMZ_PREFERENCE+<+SMZ_VFUNCPTR
#undef+SMZ_PREFERENCE
#define+SMZ_PREFERENCE+SMZ_VFUNCPTR
#endif

//+STEP+4.+Make+sure+we+have+something+chosen.

#if+SMZ_PREFERENCE+<=+0
#error+No+secure_memzero+implementation+available
#endif

//+STEP+5.+Use+implementation+with+highest+preference.+Ties+are+broken+in
//+favor+of+implementations+appearing+first,+below.

#if+SMZ_PREFERENCE+==+SMZ_SECUREZEROMEMORY
#define+secure_memzero(ptr,len)+SecureZeroMemory((ptr),(len))

#elif+SMZ_PREFERENCE+==+SMZ_MEMSET_S
#define+secure_memzero(ptr,len)+memset_s((ptr),(len),0,(len))

#elif+SMZ_PREFERENCE+==+SMZ_ASM_BARRIER
#define+secure_memzero(ptr,len)+do+{+\
++++memset((ptr),0,(len));+\
++++__asm__+__volatile__(""+::"r"(ptr):+"memory");+\
}+while+(0)

#elif+SMZ_PREFERENCE+==+SMZ_VDATAPTR
static+void+secure_memzero(void+*+ptr,+size_t+len)+{
++++volatile+char+*+p+=+ptr;
++++while+(len--)+*p%2B%2B+=+0;
}

#elif+SMZ_PREFERENCE+==+SMZ_VFUNCPTR
static+void+*+(*+volatile+_smz_memset_fptr)(void*,int,size_t)+=+&memset;
static+void+secure_memzero(void+*+ptr,+size_t+len)+{
++++_smz_memset_fptr(ptr,+0,+len);
}

#endif

#endif+//+_SECURE_MEMZERO_H_|code-block|syntax|javascript|394208|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|0|31|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|14|8|@]|9|@$L|15|M|16|1|17]]|A|$]]|$1|N|3|O|5|P|7|18|8|@]|9|@]|A|$Q|R]]|$1|S|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|K]]]]

&quot;When we free() memory in C, why is that memory not filled with zero?&quot;
Generally speaking, not requiring every freed block of memory to be zeroed upon deallocation lets the compiler generate better code.
&quot;Is there a good way to ensure this happens as a matter of course when calling free()?&quot;
Not really. There are many attempts to solve dead store elimination, but they all have issues with compliance or portability.
This presentation does a great job of summarizing this nuanced issue, and provides a link to their solution's source code, which is reprinted here.
<a href="https://www.usenix.org/sites/default/files/conference/protected-files/usenixsecurity17_slides_zhaomo_yang.pdf" rel="nofollow noreferrer">https://www.usenix.org/sites/default/files/conference/protected-files/usenixsecurity17_slides_zhaomo_yang.pdf</a>
<pre><code>// secure_memzero.h version 1 (October 29, 2016)
// 
// This code is released into the public domain.
//
// THIS SOFTWARE IS PROVIDED &quot;AS IS&quot; AND ANY EXPRESS OR IMPLIED WARRANTIES,
// INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
// FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
// AUTHORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
// OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
// SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
// INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
// CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
// ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
// POSSIBILITY OF SUCH DAMAGE.

// The secure_memzero macro/function attempts to ensure that an optimizing
// compiler does not remove the intended operation if cleared memory is not
// accessed again by the program. There are several known ways of doing this,
// however no single one is both universally available and absolutely guranteed
// by the standard. The following code defines secure_memzero as a macro or
// function using one of the known alternatives. The choice of implementation
// can be controlled by defining a preprocessor macro of the form SMZ_impl,
// where &lt;impl&gt; is one of the defined implementation names. SMZ_impl should
// expand to an integer indicating the dgeree of preference for the
// implementation, where numerically higher values indicate greater preference.
// Defining SMZ_impl to be 0 disables the implementation even if it is
// available. Not defining any SMZ_impl will result in default (safe) behavior.
// 
// The following implementations may be used.
// 
// SMZ_SECUREZEROMEMORY
// Uses the SecureZeroMemory macro/function on Windows. Requires a Windows
// environment (_WIN32 must be defined).
// 
// SMZ_ASM_BARRIER
// Uses a compiler memory barrier to force the results of a memset to be
// committed to memory. Has been tested to work on:
// - Clang 3.9.0 at all optimization levels.
// - GCC 6.2 at all optimization levels.
// 
// SMZ_MEMSET_S
// Uses the C11 function memset_s. Currently not available on many platforms.
// Note that if you want this option, you have to set __STDC_WANT_LIB_EXT1__
// to 1 before including string.h or any file that includes string.h in a
// compilation unit that includes this header.
// 
// SMZ_VDATAPTR
// Uses the volatile data pointer technique to zero one byte at a time. This is
// not guaranteed to work by the C standard, which does not require access to
// non-volatile objects via a pointer-to-volatile to be treated as a volatile
// access. However, it is known to work on the following compilers:
// - Clang 3.9.0 at all optimization levels.
// - GCC 6.2 at all optimization levels.
// 
// SMZ_VFUNCPTR
// Uses the volatile function pointer technique to call memset. This is not
// guaranteed to work by the C standard, which does not require the pointed-to
// function to be called. However, it is known to work on the following
// compilers:
// - Clang 3.9.0 at all optimization levels.
// - GCC 6.2 at all optimization levels.

// The remainder of this file implements the selection logic using the
// specified compile-time preferences.

#ifndef _SECURE_MEMZERO_H_
#define _SECURE_MEMZERO_H_

// STEP 1. Set default preference for all implementations to 1.

#ifndef SMZ_SECUREZEROMEMORY
#define SMZ_SECUREZEROMEMORY 1
#endif

#ifndef SMZ_MEMSET_S
#define SMZ_MEMSET_S 1
#endif

#ifndef SMZ_ASM_BARRIER
#define SMZ_ASM_BARRIER 1
#endif

#ifndef SMZ_VDATAPTR
#define SMZ_VDATAPTR 1
#endif

#ifndef SMZ_VFUNCPTR
#define SMZ_VFUNCPTR 1
#endif

// STEP 2. Check which implementations are available and include any necessary
// header files.

#if SMZ_SECUREZEROMEMORY &gt; 0
#ifdef _WIN32
#include &lt;windows.h&gt;
#else
#undef SMZ_SECUREZEROMEMORY
#define SMZ_SECUREZEROMEMORY 0
#endif
#endif

#if SMZ_MEMSET_S &gt; 0
#if defined(__STDC_WANT_LIB_EXT1__) &amp;&amp; (__STDC_WANT_LIB_EXT1__ != 1)
#undef SMZ_MEMSET_S
#define SMZ_MEMSET_S 0
#endif
#if SMZ_MEMSET_S &gt; 0
#ifndef __STDC_WANT_LIB_EXT1__
// Must come before first include of string.h
#define __STDC_WANT_LIB_EXT1__ 1
#endif
#include &lt;string.h&gt;
#ifndef __STDC_LIB_EXT1__
#undef SMZ_MEMSET_S
#define SMZ_MEMSET_S 0
#endif
#endif
#endif

#if !defined(__GNUC__) &amp;&amp; !defined(__clang__)
#undef SMZ_ASM_BARRIER
#define SMZ_ASM_BARRIER 0
#endif

#if SMZ_VFUNCPTR &gt; 0
#include &lt;string.h&gt;
#endif

// STEP 3. Calculate highest preference.

#define SMZ_PREFERENCE 0

#if SMZ_PREFERENCE &lt; SMZ_SECUREZEROMEMORY
#undef SMZ_PREFERENCE
#define SMZ_PREFERENCE SMZ_SECUREZEROMEMORY
#endif

#if SMZ_PREFERENCE &lt; SMZ_MEMSET_S
#undef SMZ_PREFERENCE
#define SMZ_PREFERENCE SMZ_MEMSET_S
#endif

#if SMZ_PREFERENCE &lt; SMZ_ASM_BARRIER
#undef SMZ_PREFERENCE
#define SMZ_PREFERENCE SMZ_ASM_BARRIER
#endif

#if SMZ_PREFERENCE &lt; SMZ_VDATAPTR
#undef SMZ_PREFERENCE
#define SMZ_PREFERENCE SMZ_VDATAPTR
#endif

#if SMZ_PREFERENCE &lt; SMZ_VFUNCPTR
#undef SMZ_PREFERENCE
#define SMZ_PREFERENCE SMZ_VFUNCPTR
#endif

// STEP 4. Make sure we have something chosen.

#if SMZ_PREFERENCE &lt;= 0
#error No secure_memzero implementation available
#endif

// STEP 5. Use implementation with highest preference. Ties are broken in
// favor of implementations appearing first, below.

#if SMZ_PREFERENCE == SMZ_SECUREZEROMEMORY
#define secure_memzero(ptr,len) SecureZeroMemory((ptr),(len))

#elif SMZ_PREFERENCE == SMZ_MEMSET_S
#define secure_memzero(ptr,len) memset_s((ptr),(len),0,(len))

#elif SMZ_PREFERENCE == SMZ_ASM_BARRIER
#define secure_memzero(ptr,len) do { \
 memset((ptr),0,(len)); \
 __asm__ __volatile__(&quot;&quot; ::&quot;r&quot;(ptr): &quot;memory&quot;); \
} while (0)

#elif SMZ_PREFERENCE == SMZ_VDATAPTR
static void secure_memzero(void * ptr, size_t len) {
 volatile char * p = ptr;
 while (len--) *p++ = 0;
}

#elif SMZ_PREFERENCE == SMZ_VFUNCPTR
static void * (* volatile _smz_memset_fptr)(void*,int,size_t) = &amp;memset;
static void secure_memzero(void * ptr, size_t len) {
 _smz_memset_fptr(ptr, 0, len);
}

#endif

#endif // _SECURE_MEMZERO_H_
</code></pre>

When we <code>free()</code> memory in C, why is that memory not filled with zero? Is there a good way to ensure this happens as a matter of course when calling <code>free()</code>? 

I'd rather not risk leaving sensitive data in memory released back to the operating system...

Why doesn't free() zero out the memory prior to releasing it?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

当我们在C中free()内存的时候，为什么内存没有填满0呢？在调用free()时，有没有好的方法来确保这是理所当然的呢？我不想冒险把敏感数据留在内存中，释放回操作系统……

问为什么不在释放内存之前把free()清零呢？
EN

回答 15

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么不在释放内存之前把free()清零呢？EN

回答 15

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么不在释放内存之前把free()清零呢？
EN