@MSGID: Lpcc.11499@fx42.iad>
d93a5276
@REPLY: 1@dont-email.me> fefb474d
@REPLYADDR Charlie Gibbs
<cgibbs@kltpzyxm.invalid>
@REPLYTO 2:5075/128 Charlie Gibbs
@CHRS: CP866 2
@RFC: 1 0
@RFC-References: 1@dont-email.me>
<ygamsxoixhx.fsf@akutech.de> 4@dont-email.me> <ygail8biyxm.fsf@akutech.de>
1@dont-email.me> <ygaedizitb9.fsf@akutech.de> 2@dont-email.me>
5Arqz@news.chiark.greenend.org.uk> 1@dont-email.me> 1@dont-email.me>
@RFC-Message-ID:
Lpcc.11499@fx42.iad>
@TZUTC: 0000
@PID: slrn/1.0.3 (Linux)
@TID: FIDOGATE-5.12-ge4e8b94
On 2023-09-15, Rich <rich@example.invalid> wrote:

> In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> I had assumed that freeing a pointer that already had been freed would 
>> either result in a NO-OP because the pointer no longer existed in the 
>> heap memory allocation tables, or it would instantly crash , but it 
>> seems that the action is `undefined`.
>
> Yes, C explicitly labels "double free" as "undefined":
>
> <http://port70.net/~nsz/c/c99/n1256.html#J.2>
>
> Look under J.2 Undefined behavior (easiest is to search for "free"):
>
>     J.2 Undefined behavior
>
>     1 The behavior is undefined in the following circumstances: 
>
>     ...
>
>     The pointer argument to the free or realloc function does not match 
>     a pointer earlier returned by calloc, malloc, or realloc, or the 
>     space has been deallocated by a call to free or realloc (7.20.3.2, 
>     7.20.3.4).
>
> And th 7.20.3.2 link in the page jumps to this:
>
>     The free function causes the space pointed to by ptr to be 
>     deallocated, that is, made available for further allocation.  If 
>     ptr is a null pointer, no action occurs.  Otherwise, if the 
>     argument does not match a pointer earlier returned by the calloc, 
>     malloc, or realloc function, or if the space has been deallocated 
>     by a call to free or realloc, the behavior is undefined.
>
> So if by chance you are double-freeing sometimes, then you are tickling 
> the undefined behaviour devil, and all bets are off as to what might 
> eventually occur.

That`s why I take steps to avoid it.  Since files and dynamically-
allocated memory are global resources, I declare file and memory
pointers as global variables.  I initialize them to NULL as an
indication that the file is not open or memory is not allocated.
If fopen() or malloc() fails, the pointer remains NULL and serves
as an indication of failure.  When I close a file or free a block
of memory, I immediately set the corresponding pointer to NULL.
All my programs exit through a routine I call quit_cleanup(),
which closes files or frees memory for any non-NULL pointer
before calling exit().  I can call this function at any time
(e.g. to force abnormal termination) and everything will be
appropriately freed.  Similarly, I can check a pointer for
non-NULL before opening a file or allocating memory (although
realloc() takes care of that automatically).  It`s quite
effective in avoiding resource leaks as well as the undefined
behaviour mentioned above.

-- 
/~\\  Charlie Gibbs                  |  They offer a huge range of
\\ /  <cgibbs@kltpzyxm.invalid>      |  world-class vulnerabilities
 X   I`m really at ac.dekanfrus     |  that only Microsoft can provide.
/ \\  if you read it the right way.  |    -- druck <news@druck.org.uk>
--- slrn/1.0.3 (Linux)
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441