From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.252.6 with SMTP id zo6mr13748622pac.40.1406465236963; Sun, 27 Jul 2014 05:47:16 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!h18no5235811igc.0!news-out.google.com!j6ni19359qas.0!nntp.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Sun, 27 Jul 2014 07:47:16 -0500 Date: Sun, 27 Jul 2014 08:47:15 -0400 From: Peter Chapin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Deallocating an object twice References: In-Reply-To: Message-ID: X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-Vvto/79ABLUkEzsA0MN124IsrndGPTxw/CHn3RVEzxmZw8m3SsQdH2IOCmD4W/MpMxpJhFwAH0DX5Oc!T43W7Tks+fTCDqrJDhPHnRz5nREM7fYeG7jo2hlLkbEJ6mdjOIwlHm/yDU270f0= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 2275 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Received-Bytes: 2578 X-Received-Body-CRC: 1655510588 Xref: news.eternal-september.org comp.lang.ada:21280 Date: 2014-07-27T08:47:15-04:00 List-Id: On 2014-07-27 07:30, anon@att.net wrote: > For most OS, deallocation of memory happens only if the program > exits and returns it's allocated resources back to the OS. And > for speed the underlying C library routine "free" does not truly > deallocate or mark the memory as unused. C's free() marks the memory as unused in the sense that a future call to malloc() might use memory that was previously freed. If that were not the case it wouldn't be possible, even in principle, to write a C program that didn't leak memory. What you're talking about is happening at a lower level. It may be the case that once a block of memory is requested from the OS, the C library never releases it. As you say, the OS reclaims the memory when the process terminates. However, the C library will still distinguish between used and unused memory within the allocation it has. A program that loops forever repeatedly allocating and freeing memory for a single integer, say, could run infinitely without ever exhausting storage or requesting additional memory from the OS. It will simply reuse the space it already has. Peter