is there any way to find out number of bytes freed on a particular
free() call in C
When you allocate this storage, you know how much storage you allocated.
Don't Forget.
Then, when you come to free it, you know, right?
--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
is there any way to find out number of bytes freed on a particular
free() call in C
The only portable way is to store that information when you initially
allocate the memory (and update it if you subsequently successfully
call realloc using that pointer). If you want non-portable ways, you
could try asking in a platform specific group. Even there, it may
depend on what specific standard library implementation you are using,
and may simply not be available by any means.
On Aug 8, 7:10 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:
sh.vi...@gmail. com said:
>
is there any way to find out number of bytes freed on a particular
free() call in C
>
When you allocate this storage, you know how much storage you allocated.
>
Don't Forget.
>
Then, when you come to free it, you know, right?
>
--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
yea but then i will have to store this information (number of bytes
allocated) at the time of allocation. so also a link between a pointer
and number of bytes it is linked with ...esentially i don;t want to
write my own memory allocator.
On Aug 8, 7:10 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:
>
>
>
sh.vi...@gmail. com said:
>
is there any way to find out number of bytes freed on a particular
free() call in C
>
When you allocate this storage, you know how much storage you allocated.
>
Don't Forget.
>
Then, when you come to free it, you know, right?
>
--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
>
yea but then i will have to store this information (number of bytes
allocated) at the time of allocation. so also a link between a pointer
and number of bytes it is linked with ...esentially i don;t want to
write my own memory allocator.
Don't quote sig blocks.
see rfc 2646 4.3
If you don't want to do something, then don't. Simple, isn't it?
On Aug 8, 7:06 pm, David Resnick <lndresn...@gma il.comwrote:
On Aug 8, 9:58 am, sh.vi...@gmail. com wrote:
>
is there any way to find out number of bytes freed on a particular
free() call in C
>
The only portable way is to store that information when you initially
allocate the memory (and update it if you subsequently successfully
call realloc using that pointer). If you want non-portable ways, you
could try asking in a platform specific group. Even there, it may
depend on what specific standard library implementation you are using,
and may simply not be available by any means.
>
-David
ok . agreed. i hoped there might be some standard way in which guard
bytes store the information about the allocated memory. if it is
library specific there might not be any way for this. because then
libararies even might not even allocate gurad byte alongwith the data.
On Aug 8, 7:10 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:
>sh.vi...@gmail .com said:
>>
is there any way to find out number of bytes freed on a particular
free() call in C
>>
>When you allocate this storage, you know how much storage you
>allocated.
>>
>Don't Forget.
yea but then i will have to store this information (number of bytes
allocated) at the time of allocation. so also a link between a pointer
and number of bytes it is linked with ...esentially i don;t want to
write my own memory allocator.
This is not possible in Standard C. But many implementations of C do
provide extensions for this rather commonly felt need. You should ask
in a group for your implementation, or better yet, just read the
documentation for your system's C library.
On Aug 8, 7:10 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:
>sh.vi...@gmail .com said:
>>
is there any way to find out number of bytes freed on a particular
free() call in C
>>
>When you allocate this storage, you know how much storage you allocated.
>>
>Don't Forget.
>>
>Then, when you come to free it, you know, right?
>>
yea but then i will have to store this information (number of bytes
allocated) at the time of allocation.
Right. You can't have something for nothing. If you want to remember, it
will take up some memory.
so also a link between a pointer
and number of bytes it is linked with ...esentially i don;t want to
write my own memory allocator.
Then don't!
Why do you care how many bytes are freed? (No, I know it's none of my
business, but it may well be that there is a simple solution to your
underlying problem.)
--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
In article <icSdnWtxcvhAzw HVnZ2dnUVZ8uydn Z2d@bt.com>,
Richard Heathfield <rjh@see.sig.in validwrote:
>sh.vipin@gmail .com said:
>is there any way to find out number of bytes freed on a particular
>free() call in C
>When you allocate this storage, you know how much storage you allocated.
>Don't Forget.
>Then, when you come to free it, you know, right?
The number of bytes of the allocation request is not necessarily
the same as the number of bytes freed.
When one makes an allocation request, one might be given a pointer into
the middle of of chunk of memory, with the initial part used as
overhead by the memory allocator; for example in some memory
allocators, it might be used to contain the size of the object.
Or the allocator might choose to allocate in quantums of a particular
size, or the allocator might use a binary page-splitting algorithm,
so the size of the object actually allocated and pointed to might
be larger than the size requested.
When the free() call is made, all of these overhead bytes and
extra bytes are freed -- so the number of bytes freed does not
necessarily match the number of bytes allocated.
--
"Whenever there is a hard job to be done I assign it to a lazy
man; he is sure to find an easy way of doing it."
-- Walter Chrysler
In article <g7hlv7$9c$1@ca nopus.cc.umanit oba.ca>,
Walter Roberson <roberson@ibd.n rc-cnrc.gc.cawrote :
>When the free() call is made, all of these overhead bytes and
>extra bytes are freed -- so the number of bytes freed does not
>necessarily match the number of bytes allocated.
Opps, I meant "so the number of bytes freed does not necessarily
match the number of bytes requested for allocation."
--
"Allegories are in the realm of thoughts, what ruins are in
the realm of things." -- Walter Benjamin
On Aug 8, 7:52 pm, Chris Dollin <chris.dol...@h p.comwrote:
sh.vi...@gmail. com wrote:
is there any way to find out number of bytes freed on a particular
free() call in C
>
Not portably.
>
Usually you don't need to know; free frees what malloc malloced.
>
What is it that you'd do with the answer, were you to have it?
>
--
'It changed the future .. and it changed us.' /Babylon 5/
>
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
i am writing a simple application where i want to keep track of number
of bytes my process is using currently or peak memory used by my
process so far. i thought of using xyz_malloc() in stead of malloc
everywhere in my application and inside xyz_malloc add the count of
requested amount to a global variable. but when i have to free it i
need to reduce that count.
i can modify xyz_mallo() to solve this problem such that when asked to
allocate N number of bytes, allocate N+1 and return pointer to the 1st
onwards (not 0th) byte as a new memory to aplication and in first byte
store the number of bytes allocated. but it might cause serious
alignment problem
yea, probably my problem is not hard enough to require a memory
manager to be written. probably there must be some API to tell me
current memory usage.
if you know please let me know, but i would like to do some googling
my own before taking your valuable time on this.
On Aug 8, 7:52 pm, Chris Dollin <chris.dol...@h p.comwrote:
>sh.vi...@gmail .com wrote:
>>is there any way to find out number of bytes freed on a particular
>>free() call in C
>Not portably.
>>
>Usually you don't need to know; free frees what malloc malloced.
>>
>What is it that you'd do with the answer, were you to have it?
>>
>--
>'It changed the future .. and it changed us.' /Babylon 5/
>>
>Hewlett-Packard Limited registered no:
>registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
>
>
i am writing a simple application where i want to keep track of number
of bytes my process is using currently or peak memory used by my
process so far. i thought of using xyz_malloc() in stead of malloc
everywhere in my application and inside xyz_malloc add the count of
requested amount to a global variable. but when i have to free it i
need to reduce that count.
Your best bet is probably to use a system-specific tool to view
your program's memory consumption "from the outside," rather than
trying to get the information from inside the program. That's because
your program's total memory use certainly involves storage that your
code does not request from malloc() et al.: storage for code, for
static data, for automatic data ("the stack"), for I/O buffers and
suchlike things inside libraries ... Also, the usual reason to keep
track of things like peak memory usage is to monitor the health of
the system as a whole, not just of one program, so an external tool
is usually more useful because it can see many programs at once.
On Unixoid systems look for things like "top" or "prstat" or "ps"
or "pmap" or "vmstat."
That said, some implementations have system-specific ways to find
out things about your program's dynamically-allocated memory. See
if your system has a mallinfo() function and/or a <malloc.hheader ,
and check the system's documentation for how to use them and what
you can find out from them.
i can modify xyz_mallo() to solve this problem such that when asked to
allocate N number of bytes, allocate N+1 and return pointer to the 1st
onwards (not 0th) byte as a new memory to aplication and in first byte
store the number of bytes allocated. but it might cause serious
alignment problem
There are a couple of ways to cope with the alignment issue;
study the source code for actual allocators to get ideas. But you
still may be stuck with the problem of memory allocated by the
library -- your code may call xyz_malloc(), but fopen() most likely
gets its buffer memory from regular malloc() and thus "flies under
your radar."
yea, probably my problem is not hard enough to require a memory
manager to be written. probably there must be some API to tell me
current memory usage.
if you know please let me know, but i would like to do some googling
my own before taking your valuable time on this.
If you read this newsgroup for a while, you'll probably conclude
that many of us have *way* too much time on their hands ...
>
is there any way to find out number of bytes freed on a particular
free() call in C
No portable means. When you malloc (realloc, calloc) 'ed the item
you specified what you wanted. You can assume you got that much
back. However malloc can assign more than the requested memory
(for alignment maintenance reasons) in which case you will get back
more.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.
In article <icSdnWtxcvhAzw HVnZ2dnUVZ8uydn Z2d@bt.com>,
Richard Heathfield <rjh@see.sig.in validwrote:
>>sh.vipin@gmai l.com said:
>
>>is there any way to find out number of bytes freed on a particular
>>free() call in C
>
>>When you allocate this storage, you know how much storage you allocated.
>
>>Don't Forget.
>
>>Then, when you come to free it, you know, right?
>
The number of bytes of the allocation request is not necessarily
the same as the number of bytes freed.
True, but not particularly important in the grand scheme of things as far
as the abstract machine is concerned. When you request an allocation, it
either works or it doesn't. If it doesn't, tough. If it does, the most
number of bytes you can rely on having is the number you asked for - any
overhead is the implementation' s business, not yours. So if you think of
your program in abstract terms (as I tend to do), the allocation
*effectively* only gives you the N bytes you asked for (even if there is
some behind-the-scenes overhead going on), and therefore when you free
that block you *effectively* free N bytes. Yes, there may be overhead, but
no, from an abstract machine perspective it turns out not to matter to
your program.
If you move away from the abstract machine, and want to know how much
*actual* memory is being booted from pillar to post and back, then you're
into the realms of implementation-specific extensions, which are
considered atopical in clc.
In other words, I think we both know what we both mean, and we're both
right in our own sweet way. :-)
<snip>
--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Comment