Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Checking validity of a file pointer

Reply
Thread Tools

Re: Checking validity of a file pointer

 
 
Keith Thompson
Guest
Posts: n/a
 
      01-15-2010
"io_x" <(E-Mail Removed)> writes:
> "Keith Thompson" <(E-Mail Removed)> ha scritto nel messaggio
> news:(E-Mail Removed)...

[...]
>> p1 = malloc(...);
>> free(p1);
>>
>> p2 = malloc(...); /* p2 happens to point to the same location that
>> p1 previously pointed to */
>> free(p1); /* oops! */
>>
>> The free(p1) call invokes undefined behavior, but without substantial
>> extra work there's no way the implementation can detect the problem.

>
> yes there is some,
> if i remember well what i wrote, my home made free sees the list of pointers
> returned from malloc; if the pointer is not present in that list it
> call exit() function and show in stderr, the sys want to free one pointer
> that is not in the malloc list


And how would that catch the error in the code snippet above?

> Because when i write routines i write memory like a stack
> a1=malloc(23);
> a2=malloc(24);
> ...
> free(a2)
> free(a1)
> and because free linear search from the last to the first
> the order of linear reserch is always O(1) (for my routines)
> or at last i think that


Sure, if you consistently allocate and free in a stack-like manner,
you can avoid certain errors. But what if you don't?

> don't know very well how fast it would be if i not follow the stack
> model of malloc-free memory above...


--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      01-16-2010
"io_x" <(E-Mail Removed)> writes:
> "Keith Thompson" <(E-Mail Removed)> ha scritto nel messaggio
> news:(E-Mail Removed)...
>> "io_x" <(E-Mail Removed)> writes:
>>> "Keith Thompson" <(E-Mail Removed)> ha scritto nel messaggio
>>> news:(E-Mail Removed)...

>> [...]
>>>> p1 = malloc(...);
>>>> free(p1);
>>>>
>>>> p2 = malloc(...); /* p2 happens to point to the same location that
>>>> p1 previously pointed to */
>>>> free(p1); /* oops! */
>>>>
>>>> The free(p1) call invokes undefined behavior, but without substantial
>>>> extra work there's no way the implementation can detect the problem.
>>>
>>> yes there is some, if i remember well what i wrote, my home made
>>> free sees the list of pointers returned from malloc; if the
>>> pointer is not present in that list it call exit() function and
>>> show in stderr, the sys want to free one pointer that is not in
>>> the malloc list

>>
>> And how would that catch the error in the code snippet above?

>
> after the first free(p1) that "p1" is not more a pointer in the list
> of malloc memory, so when there is the other free(p1), free() not
> find p1 in the list (linear search) of mallokked pointers and make
> the program to exit because the sys want free one pointer not
> returned from malloc


But "p1" isn't in the list; the value that was assigned to "p1" is in
the list. malloc has no way of knowing what the caller did with the
result.

Here's what (probably) happens in a bit more detail. We'll assume
that the system maintains a list of malloced pointers.

p1 = malloc(100);
/* p1 obtains the value, let's say, (void*)0x8446008.
* The system adds 0x8446008 to a list of malloced pointers.
* (Note that it doesn't add p1 to the list; malloc doesn't
* know about p1.
*/

free(p1);
/* In principle, the value of p1 is now indeterminate.
* In practice, it almost certainly still retains the same bit
* pattern, 0x8446008. That address is removed from the list
* of malloced pointers, which is now empty.
*/

p2 = malloc(100);
/* We know there's a free block of at least 100 bytes starting
* at (void*)0x8446008. malloc() may or may not return that
* same address again. Let's assume it does. So now
* p2 == (void*)0x8446008. And p2 still has that same value.
* 0x8446008 is now on the malloc list again.
*/

free(p1);
/* This is incorrect; we meant to write free(p2).
* But all the system knows is that 0x8446008 is on its list,
* and free was just passed that address. As far as the system
* can tell, the call is perfectly valid.
*/

The problem is that, after the second malloc call, the values
stored in p1 and p2 are logically distinct; one is a pointer
(now indeterminate) to memory that's been freed, and the other
is a pointer to memory that's just been allocated. But both
pointer objects happen to hold the same bit pattern, which will be
interpreted as the same value; there's no way for the implementation
to tell the difference.

And if malloc could do the kind of checking you want it to, would it
allow the following perfectly legal code?

p1 = malloc(100);
p2 = p1;
free(p2);

[snip]

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
validity of a pointer sinbad C Programming 34 02-12-2009 01:16 AM
Validity of pointer conversions Ioannis Vranos C++ 35 01-09-2008 08:31 PM
Validity of the this pointer before the object is constructed tuko C++ 4 09-17-2004 05:04 AM
Pointer validity jacob navia C Programming 16 12-04-2003 09:05 AM
validity of using subclasses in pointer-to-pointer types? Marcus Alanen C++ 1 09-07-2003 10:42 AM



Advertisments