Let p=malloc(N) for some N>0. As far as I understand it, free(p+k) for
0<k<N causes undefined behavior, since only a pointer returned by (m|
re|c)alloc() can validly be passed to free().
This seems pretty silly. Wouldn't a better behavior of free() be to
assume that if it receives q, where q lies in some malloc()ated-and-
not-yet-free()d block starting at p, then it should interpret this as
free(p)?
Even better, the *alloc() routines could leave a spare byte between
the blocks they return so that free(p+N) would also be equivalent to
free(p).
This would let one move p around within the allocated block, without
always having to keep track of the start location of the block - a
tedious business that seems only to obfuscate one's code.
17  4138  an*********@googlemail.com wrote:
Let p=malloc(N) for some N>0. As far as I understand it, free(p+k) for
0<k<N causes undefined behavior, since only a pointer returned by (m|
re|c)alloc() can validly be passed to free().
This seems pretty silly. Wouldn't a better behavior of free() be to
assume that if it receives q, where q lies in some malloc()ated-and-
not-yet-free()d block starting at p, then it should interpret this as
free(p)?
To me it seems fairly logical; you get an object from the
the interface, then pass it back to be destroyed. It's
a common design, the confusion that can afflict beginners
is that in the case of a returned pointer from malloc the
object is both the object to be sent back to the interface
and a pointer which can be used to access a memory region.
Even better, the *alloc() routines could leave a spare byte between
the blocks they return so that free(p+N) would also be equivalent to
free(p).
This would let one move p around within the allocated block, without
always having to keep track of the start location of the block - a
tedious business that seems only to obfuscate one's code.
It's an intriguing idea, though it sounds as if it would slow
down and complicate malloc implementation (necessitating a
search for the allocated block. When do you find that keeping
the object you asked for causes obfuscation?
--
imalone an*********@googlemail.com wrote:
Let p=malloc(N) for some N>0. As far as I understand it, free(p+k) for
0<k<N causes undefined behavior, since only a pointer returned by (m|
re|c)alloc() can validly be passed to free().
`free(p+k)` is undefined for any k 0, in fact: your restriction
`<N` is misleading.
This seems pretty silly.
It seems completely reasonable to /me/. Give back what you took
out.
Wouldn't a better behavior of free() be to
assume that if it receives q, where q lies in some malloc()ated-and-
not-yet-free()d block starting at p, then it should interpret this as
free(p)?
No. Because now `free(p)` has to work out from the value of `p`
where the block you're freeing starts, and it has to do so quickly
and compactly. That's a significant constraint on the implementation.
Even better, the *alloc() routines could leave a spare byte between
the blocks they return so that free(p+N) would also be equivalent to
free(p).
I don't see why this is "better".
This would let one move p around within the allocated block, without
always having to keep track of the start location of the block - a
tedious business that seems only to obfuscate one's code.
I've never found it tedious, and I've never found it obfuscating. It's
at most one pointer with a sensible name, isn't it?
Perhaps you should exhibit an example.
--
Chris "electric hedgehog" Dollin
"Life is full of mysteries. Consider this one of them." Sinclair, /Babylon 5/ an*********@googlemail.com wrote:
Let p=malloc(N) for some N>0. As far as I understand it, free(p+k) for
0<k<N causes undefined behavior, since only a pointer returned by (m|
re|c)alloc() can validly be passed to free().
A pointer value previously returned by *alloc, yes.
This seems pretty silly. Wouldn't a better behavior of free() be to
assume that if it receives q, where q lies in some malloc()ated-and-
not-yet-free()d block starting at p, then it should interpret this as
free(p)?
Even better, the *alloc() routines could leave a spare byte between
the blocks they return so that free(p+N) would also be equivalent to
free(p).
This would let one move p around within the allocated block, without
always having to keep track of the start location of the block - a
tedious business that seems only to obfuscate one's code.
IMHO, it's cleaner to pass to free what you got from *alloc, not some
arbitrary value. Almost always you need to keep track of the start of
the block anyway, so it's not as if it's difficult.
To refrain from breaking existing implementations, the standard has
mandated this rule. It's not an inconvinient rule, and it encourages
good programming practise of preserving pointer values, before
modifying them.
>Let p=malloc(N) for some N>0. As far as I understand it, free(p+k) for
>0<k<N causes undefined behavior, since only a pointer returned by (m|
re|c)alloc() can validly be passed to free().
This seems pretty silly. Wouldn't a better behavior of free() be to
assume that if it receives q, where q lies in some malloc()ated-and-
not-yet-free()d block starting at p, then it should interpret this as
free(p)?
That's assuming the implementation keeps enough information around to
TELL if this is the case. Some don't. It may also take what's considered
by some to be too much CPU time to do that.
>Even better, the *alloc() routines could leave a spare byte between
the blocks they return so that free(p+N) would also be equivalent to
free(p).
This would let one move p around within the allocated block, without
always having to keep track of the start location of the block - a
tedious business that seems only to obfuscate one's code.
Why not ask for full garbage collection? That's more useful in more places.
Very difficult to implement efficiently, though, especially with terabyte
files open.
If you can't (or won't) keep track of where the beginning of the
block is, how do you avoid going off the beginning or the end of
it? That's a common vulnerability in software.
Chris Dollin wrote:
an*********@googlemail.com wrote:
>Let p=malloc(N) for some N>0. As far as I understand it, free(p+k)
for 0<k<N causes undefined behavior, since only a pointer returned
by (m| re|c)alloc() can validly be passed to free().
`free(p+k)` is undefined for any k 0, in fact: your restriction
`<N` is misleading.
>This seems pretty silly.
It seems completely reasonable to /me/. Give back what you took
out.
Even worse, a faulty free of some wild pointer could quietly
destroy badly needed data. Convenient does not mean safe.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
In article <45***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>Even worse, a faulty free of some wild pointer could quietly
destroy badly needed data. Convenient does not mean safe.
That can perfectly well happen with the existing specification. If
the implementation does not validate the value passed to free a bogus
value could be misinterpreted as a large block with the result that
arbitrary data could be overwritten.
It's never likely to be part of the specification of free() that it
will not destroy "badly needed data" if you pass it a "wild pointer".
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Chris Dollin wrote:
Wouldn't a better behavior of free() be to
assume that if it receives q, where q lies in some malloc()ated-and-
not-yet-free()d block starting at p, then it should interpret this as
free(p)?
No. Because now `free(p)` has to work out from the value of `p`
where the block you're freeing starts, and it has to do so quickly
and compactly. That's a significant constraint on the implementation.
I don't think it's much of a constraint. The allocator has to keep a
list of the pointers it's returned and the number of bytes they point
to, so it would just be a case of free() testing something like
"p < pall[i] + bytesall[i]" instead of "p == pall[i]" if it's passed
p.
I've never found it tedious, and I've never found it obfuscating. It's
at most one pointer with a sensible name, isn't it?
Perhaps you should exhibit an example.
How about a snippet like this?
char *p=malloc(100);
fuzzbar(p,100, otherstuff); /* does something; fuzzbar promises to
null-terminate the buffer it's passed
*/
while(*p++) {
/* stuff */
}
free(p);
would work for the implementation I suggest, with no need to keep a
copy
of the pointer returned by malloc() hanging around.
In article <11*********************@v33g2000cwv.googlegroups. com>,
<an*********@googlemail.comwrote:
>No. Because now `free(p)` has to work out from the value of `p`
where the block you're freeing starts, and it has to do so quickly
and compactly. That's a significant constraint on the implementation.
>I don't think it's much of a constraint. The allocator has to keep a
list of the pointers it's returned and the number of bytes they point
to
No, that would not be a realistic way to implement malloc(). A common
method is to store the size immediately before the block, so that the
size can be found by something like ((size_t *)block)[-1].
Another technique is to use different areas of memory for different
size blocks so that the size can be derived from the high-order
address bits, something like size_table[(intptr_t)block >NBITS].
This one could be adapted straightforwardly to work with free()
applied to an internal pointer; the size computation would still work
and the start of the block could be found by taking the address mod
the discovered block size (I believe such implementations generally
only use a small number of block sizes).
>How about a snippet like this?
char *p=malloc(100);
fuzzbar(p,100, otherstuff); /* does something; fuzzbar promises to
null-terminate the buffer it's passed
*/
while(*p++) {
/* stuff */
}
At this point p might be block+100, which might be the start of another
malloc()ed block. But in any case, I don't see that it's worth it.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Richard Tobin wrote:
At this point p might be block+100, which might be the start of
another malloc()ed block. But in any case, I don't see that it's
worth it.
You misread my original post:
Even better, the *alloc() routines could leave a spare byte between
the blocks they return so that free(p+N) would also be equivalent to
free(p).
an*********@googlemail.com wrote:
Chris Dollin wrote:
>>Wouldn't a better behavior of free() be to
assume that if it receives q, where q lies in some malloc()ated-and-
not-yet-free()d block starting at p, then it should interpret this as
free(p)?
No. Because now `free(p)` has to work out from the value of `p`
where the block you're freeing starts, and it has to do so quickly
and compactly. That's a significant constraint on the implementation.
I don't think it's much of a constraint. The allocator has to keep a
list of the pointers it's returned and the number of bytes they point
to, so it would just be a case of free() testing something like
"p < pall[i] + bytesall[i]" instead of "p == pall[i]" if it's passed
p.
For "the allocator has to" read "the allocator might."
On the other hand, the allocator might not. One common
technique (mentioned elsethread) is for the allocator to
store its metadata at a fixed distance from the allocated
block, usually just before it. Another might be for the
allocator to store the metadata in a hash table, keyed by
the bit pattern of the returned pointer. Either strategy
requires that the free() argument be a perfect match for
the value returned by *alloc().
For my own use in debugging I've written a memory package
that does in fact keep lists of allocated and free areas, trying
to keep the metadata "remote" from the areas themselves to avoid
damage from simple off-by-one and overrun errors. (I use a skip
list keyed on the address values; as written this is not portable
because it relies on being able to use < and on pointers that
are not necessarily "related.") Given such lists it would be
easy to do what you want -- but the lists chew up a significant
amount of memory and their maintenance takes significant time.
If you don't mind spending time and memory to get the behavior
you want (and if you can stomach the abuse of < and >), you are
of course at liberty to write my_malloc() and my_free() to do
this for yourself. But inflicting the overhead on every user
of malloc() seems like too many bucks for too little bang.
--
Eric Sosman es*****@acm-dot-org.invalid
Richard Tobin wrote:
CBFalconer <cb********@maineline.netwrote:
>Even worse, a faulty free of some wild pointer could quietly
destroy badly needed data. Convenient does not mean safe.
That can perfectly well happen with the existing specification.
If the implementation does not validate the value passed to free
a bogus value could be misinterpreted as a large block with the
result that arbitrary data could be overwritten.
It's never likely to be part of the specification of free() that
it will not destroy "badly needed data" if you pass it a "wild
pointer".
Certainly, but the resistance to a wild free is a QOI factor. The
nmalloc package performs some elementary checks (not unbeatable) to
avoid any such. Continuing would require the user to catch
SIGABRT, which is possible because the memory arena is not yet
fouled.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> an*********@googlemail.com wrote:
Chris Dollin wrote:
>>
>>Wouldn't a better behavior of free() be to assume that if it
receives q, where q lies in some malloc()ated-and-not-yet-free()d
block starting at p, then it should interpret this as free(p)?
No. Because now `free(p)` has to work out from the value of `p`
where the block you're freeing starts, and it has to do so quickly
and compactly. That's a significant constraint on the implementation.
I don't think it's much of a constraint. The allocator has to keep a
list of the pointers it's returned and the number of bytes they point
to, so it would just be a case of free() testing something like
"p < pall[i] + bytesall[i]" instead of "p == pall[i]" if it's passed
p.
Which involves searching a list of possibly millions of allocated
memory chunks.
>
>I've never found it tedious, and I've never found it obfuscating.
It's at most one pointer with a sensible name, isn't it?
Perhaps you should exhibit an example.
How about a snippet like this?
char *p=malloc(100);
fuzzbar(p,100, otherstuff); /* does something; fuzzbar promises to
null-terminate the buffer it's passed
*/
while(*p++) {
/* stuff */
}
free(p);
would work for the implementation I suggest, with no need to keep a
copy of the pointer returned by malloc() hanging around.
Except, at best, free becomes an O(n) operation, where n is the
number of mallocations made. This can be a killer. Just such a
fault was the impetus for creating nmalloc.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
In article <11**********************@a75g2000cwd.googlegroups .com>,
<an*********@googlemail.comwrote:
>You misread my original post:
s/misread/forgot/
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
CBFalconer <cb********@yahoo.comwrites:
an*********@googlemail.com wrote:
[...]
>How about a snippet like this?
char *p=malloc(100);
fuzzbar(p,100, otherstuff); /* does something; fuzzbar promises to
null-terminate the buffer it's passed
*/
while(*p++) {
/* stuff */
}
free(p);
would work for the implementation I suggest, with no need to keep a
copy of the pointer returned by malloc() hanging around.
Except, at best, free becomes an O(n) operation, where n is the
number of mallocations made. This can be a killer. Just such a
fault was the impetus for creating nmalloc.
If the malloc subsystem keeps track of every current allocation,
there's no reason to assume that it can only search linearly. It
could easily use a binary tree, for example; finding the base address
of a block given an arbitrary address within the block could be
O(n log n). You could probably use a hash table, making it
potentially O(1), but the fact that you're searching for a range
rather than a specific value makes it more difficult; I'm too lazy to
work out the details.
But the overhead, even if it's O(1) would still be significant. It's
perfectly reasonable, I think, to place the burden on the programmer
to pass to free() the exact same pointer value was returned by
malloc().
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>If the malloc subsystem keeps track of every current allocation,
there's no reason to assume that it can only search linearly. It
could easily use a binary tree, for example; finding the base address
of a block given an arbitrary address within the block could be
O(n log n). You could probably use a hash table, making it
potentially O(1), but the fact that you're searching for a range
rather than a specific value makes it more difficult; I'm too lazy to
work out the details.
In another posting I described a BIBOP ("big bag of pages") style
allocator for which finding the base would be O(1) and quite simple:
the high order bits of the address determine the size, and finding
the base would just be a mod operation.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Eric Sosman wrote:
>
.... snip ...
>
For my own use in debugging I've written a memory package
that does in fact keep lists of allocated and free areas, trying
to keep the metadata "remote" from the areas themselves to avoid
damage from simple off-by-one and overrun errors. (I use a skip
list keyed on the address values; as written this is not portable
because it relies on being able to use < and on pointers that
are not necessarily "related.") Given such lists it would be
easy to do what you want -- but the lists chew up a significant
amount of memory and their maintenance takes significant time.
If you don't mind spending time and memory to get the behavior
you want (and if you can stomach the abuse of < and >), you are
of course at liberty to write my_malloc() and my_free() to do
this for yourself. But inflicting the overhead on every user
of malloc() seems like too many bucks for too little bang.
Take a look at the way nmalloc, combined with malldbg, handles this
(at least on suitable systems, which should include most Linae).
See nmalloc.zip, at:
<http://cbfalconer.home.att.net/download/>
There is no (or very little) overhead imposed on users of malloc,
free, realloc. Yet the entire arena can be (and is, via malldbg)
scanned for usage and self-consistency. Since the basic storage
provided by sbrk can be discontinuous, a table of bases is
maintained. Memory leaks can be quickly detected by scans before
and after program runs (since malloc and friends may be used by the
initialization code, outside the program proper). If there is no
leak there will only be free blocks, and all should have been
combined, apart from the storage claimed and not released by the
initialization. Some systems will not use malloc during
initialization, in which case nothing should be allocated in either
scan.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> an*********@googlemail.com wrote:
Chris Dollin wrote:
>I've never found it tedious, and I've never found it obfuscating. It's
at most one pointer with a sensible name, isn't it?
Perhaps you should exhibit an example.
How about a snippet like this?
char *p=malloc(100);
fuzzbar(p,100, otherstuff); /* does something; fuzzbar promises to
null-terminate the buffer it's passed
*/
while(*p++) {
/* stuff */
}
free(p);
would work for the implementation I suggest, with no need to keep a
copy
of the pointer returned by malloc() hanging around.
Perhaps - but adding that one pointer doesn't seem to me to be
either tedious or obfuscatory, so it's not the example I was
asking for.
--
Chris "electric hedgehog" Dollin
The "good old days" used to be much better. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: c language |
last post by:
Hi All,
I have written a C++ program, it can be compiled (in UNIX) but when I
run it, I usually gives the following errors:
free(): invalid pointer 0x51d4a0!
free(): invalid pointer 0x51d460!...
|
by: KWienhold |
last post by:
I'm currently working on a project in C# (VS 2003 SP1, .Net 1.1) that
utilizes IStream/IStorage COM-Elements.
Up to now I have gotten everything to work to my satisfaction, but now
I have come...
|
by: Sebouh |
last post by:
I'm very close of shooting myself in the head right now. Why in hell does free(xx) give me an error: *** glibc detected *** free(): invalid pointer: 0x08ce6158 ***
// The function returns...
|
by: mahiapkum |
last post by:
hello all i have a code which looks fine when reviewed but when the application has a long run say for example of 2 days it gets exit, because of glibc error and the sample code is as follows:
while...
|
by: P. Adhia |
last post by:
Hello,
I was wondering if anyone is successfully using using
Python(2.5)+DB2+pydb2. I get an error in all situations. It seems that
this problem might be limited to python 2.5. A quick Google...
|
by: shrik |
last post by:
I have following error :
Total giant files in replay configuration file are :
File name : /new_file/prob1.rec
Given file /new_file/prob1.rec is successfully verified.
Splitting for giant file...
|
by: shrik |
last post by:
I have following error :
Total giant files in replay configuration file are :
File name : /new_file/prob1.rec
Given file /new_file/prob1.rec is successfully verified.
Splitting for giant file...
|
by: Cyron |
last post by:
Hello friends,
I'm getting a bizaare glibc error referencing free -- I malloc a
chunk of memory and then later when I try to free it is when the
program aborts. I've added some debug code to...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
