📄 badalloc.html

📁 this is a mirrored site c-faq. thought might need offline
💻 HTML
字号:
<html><!-- &lt;2001Dec06.2308.scs.005@aeroroot.scs.ndip.eskimo.net&gt; --><!-- Mirrored from c-faq.com/malloc/badalloc.html by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 08:02:58 GMT --><head><title></title></head><body><p>[Someone once asked me if after calling<pre>	p = malloc(strlen(string));</pre>the call<pre>	strcpy(p, string);</pre>should succeed or fail.They suspected that the <TT>strcpy</TT> call should fail,because space for the terminating <TT>\0</TT> was not allocated.They suspected that the pointer <TT>p</TT>would <em>not</em> end up pointing to a proper copy of the string,and they were surprised when it did,or seemed to.They specifically wanted to know whether(a) a later <TT>free()</TT> of <TT>p</TT> would fail,(b) the <TT>strcpy()</TT> call would fail,(c) an attempt to print the string <TT>p</TT> would succeed, or(d) there would be an error.This is a revised version of my reply.]<p>Asking exactly what will happen here is a tough question.Logically, the question is roughly equivalent to:<blockquote><p>You come to an intersection of two busy streets.The light is red, and the sign says ``Don't Walk''.You cross the street.  What happens?<p>(a) a policeman gives you a ticket<br>(b) a car hits you and you wind up in the hospital<br>(c) a car slams on its brakes and narrowly avoids hittingyou, and its driver makes various rude remarks concerningyour intelligence and your ancestry<br>(d) you reach the other side safely</blockquote><p>You are correct in observing that the code fails to allocateenough room for the '\0'.The reason it seemed to work when you tried it is thatsometimes,answer (d) in my crossing-the-busy-street-against-the-lightanalogy applies.<p>C is a relatively low-level language.  It is designed to workefficiently with individual bytes and words in memory; it only<em>seems</em> to give you access to higher-level concepts like strings.<p>The code fragment you presented above asks <TT>malloc</TT> for <i>n</i> bytesof memory.<TT>malloc</TT> returns a pointer to some memory, whichthe code proceeds to copy <i>n</i>+1 bytes of data to.  Obviously thisis wrong -- well, it's obvious to you and me, but it is <em>not</em>obvious to <TT>malloc</TT> or <TT>strcpy</TT>.  <TT>strcpy</TT> has no way of knowing howmany bytes' worth of memory it's allowed to copy to; all itreceives is a pointer to the source string and a pointer tothe destination.  In general, pointers are implemented asstraightforward memory addresses; they don't carry aroundany extra information concerning the size of the memory regionsthey point to.  In general, it's up to <em>you</em>, the programmer,to ensure that pointers point to enough memory to support theoperations you perform on them.  If the programmer fails, badthings will probably happen, but we usually can't predictprecisely what the bad things are, or precisely when they'llhappen.  All we can do is try to avoid writing incorrect codein the first place, and to remember that when we have a programthat's behaving strangely, or seeming to overwrite memory itshouldn't, or crashing with ``Segmentation Violation'' or ``BusError'' or ``General Protection Fault'', one of the things to goback and double-check during debugging is whether our pointerusage is correct.<p>When you copy more data to a <TT>malloc</TT>'ed block of data than youasked for, several things can happen, depending on how far pastthe end of the block you accidentally write, and how <TT>malloc</TT> isimplemented, and what your program tries to do next.  Often, ifyou write only a little bit too much (e.g. by forgetting toallocate space for the terminating <TT>'\0'</TT> of a string, which is ofcourse a rather common mistake), what you overwrite is some of<TT>malloc</TT>'s internal bookkeeping information.  Often, if thishappens, the <TT>malloc</TT> code won't notice until the <em>next</em> call to<TT>malloc</TT> or <TT>free</TT> (which might be some distance from the actualbug, which is one of the things that makes these bugs stubbornand hard to track down).  And sometimes, <TT>malloc</TT> allocates a bitmore space than you asked for (for its own reasons, e.g. to makethe blocks of allocated memory line up better), meaning you can(seem to) get away with overflowing the block with no penaltyat all.<p>But I hasten to add that everything in the previous paragraph is``maybe''.  You're not, of course, supposed to copy more data to a<TT>malloc</TT>'ed block than the block was <TT>malloc</TT>'ed to hold, and if youdo, all bets are off.  The program can do just about anything,including crash in various ways, or deliver obviously bogusresults, or deliver subtly wrong results that you might not evennotice.  But -- and this is actually rather unfortunate -- the``just about anything'' that the incorrect program might do alsoincludes ``doing just what you expected'' (that is, not seeming tobehave incorrectly at all), thus lulling you into a false senseof security that the code is ``correct'' -- because it ``works'' --even though it is not correct, works today only by accident, andmight very well stop working tomorrow.</body><!-- Mirrored from c-faq.com/malloc/badalloc.html by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 08:02:58 GMT --></html>
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -