how to find number of bytes freed

[sh.vipin]

is there any way to find out number of bytes freed on a particular
free() call in C

[Richard Heathfield]

sh******@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

[David Resnick]

On Aug 8, 9:58*am, [e-mail] 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

[sh.vipin]

On Aug 8, 7:10 pm, Richard Heathfield <[e-mail]:

[e-mail] 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.

[vippstar]

On Aug 8, 5:12 pm, [e-mail] wrote:

On Aug 8, 7:10 pm, Richard Heathfield <[e-mail]:

[e-mail] 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?

[sh.vipin]

On Aug 8, 7:06 pm, David Resnick <[e-mail]:

On Aug 8, 9:58 am, [e-mail] 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.

[santosh]

sh******@gmail.com wrote:

On Aug 8, 7:10 pm, Richard Heathfield <[e-mail]:

>[e-mail] 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.

[Richard Heathfield]

sh******@gmail.com said:

On Aug 8, 7:10 pm, Richard Heathfield <[e-mail]:

>[e-mail] 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

[Walter Roberson]

In article <ic******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>sh******@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

[Walter Roberson]

In article <g7*********@canopus.cc.umanitoba.ca>,
Walter Roberson <ro******@ibd.nrc-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

[Chris Dollin]

sh******@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

[sh.vipin]

On Aug 8, 7:52 pm, Chris Dollin <[e-mail]:

[e-mail] 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.

--
thanks all
vipin

[Eric Sosman]

sh******@gmail.com wrote:

On Aug 8, 7:52 pm, Chris Dollin <[e-mail]:

>[e-mail] 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 ...

--
Er*********@sun.com

[CBFalconer]

sh******@gmail.com wrote:

>
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.

[Richard Heathfield]

Walter Roberson said:

In article <ic******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>sh******@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.

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

[Walter Roberson]

In article <79**********************************@b2g2000prf.g ooglegroups.com>,
<sh******@gmail.comwrote:

>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.

On most systems, memory can only be requested from the system in
"pages" (of some system-specific size); anything left over in the
"page" that you haven't allocated yet would not be counted by your
program, but it is still "peak memory used by your process".

Counting allocated / deallocated memory also does not take into
account that due to fragmentation, there is almost always memory
allocated to your process but which is not allocated to any
particular user object (some might argue it is allocated to the
memory allocator itself, but details like that are system-specific.)

And as I mentioned in one of my previous responses, there are overhead
bytes needed by the memory allocator to track what is available or free;
those are part of your process but if you only keep a count of your
net requests then you would not be including those.
--
"Tired minds don't plan well. Sleep first, plan later."
-- Walter Reisch

[Bartc]

<sh******@gmail.comwrote in message
news:79**********************************@b2g2000p rf.googlegroups.com...

On Aug 8, 7:52 pm, Chris Dollin <[e-mail]:

>[e-mail] 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?

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 wrote a memory allocator once where it's free() function /required/ the
number of bytes to free, as the allocator did not store this. I don't
remember that this was ever a problem: usually you knew or could calculate
the N needed.

C's free() of course does not need it (although it means extra overhead to
store it somewhere). But that needn't stop you creating a function such as
free_n(P,N) and using that everywhere.

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

You will need more than 1 byte. Use 8 or 16 instead.

But, your OS might have some utility to tell your the memory usage of your
application.

--
Bartc

[Antoninus Twink]

On 8 Aug 2008 at 15:02, sh******@gmail.com wrote:

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.

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.

There is, of course, but the people here will swear blind it doesn't
exist with all the fervor of a madman claiming the sky is not blue.

For example, with gcc you can #include <malloc.hand use mallinfo().
You can also probably get information from your kernel about your
process's memory usage: for example, on Linux you could investigate
/proc/<pid>/status. How useful the information you'll get is is another
question though...

[Richard]

Richard Heathfield <rj*@see.sig.invalidwrites:

Walter Roberson said:

>In article <ic******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>>sh******@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.

True, but not particularly important in the grand scheme of things as far
as the abstract machine is concerned.

Yes. But in the real world someone wanting to know the amount used is,
err, probably actually interested in such things.

Wouldn't you think?

[Walter Roberson]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>On 8 Aug 2008 at 15:02, sh******@gmail.com wrote:

>There is, of course, but the people here will swear blind it doesn't
exist with all the fervor of a madman claiming the sky is not blue.

There are a lot of times that the sky is not blue. Like when it is
night out. Or when there are heavy clouds. Severe weather such as
close approximations of torados can turn the sky *very* strange
colors -- as can some kinds of severe snow storms.

"the sky is blue" is not a portable assumption.
--
"Why does he stagger his mind with the mathematics of the sky?
Once the question mark has arisen in the human brain the answer must
be found, if it takes a hundred years. A thousand years."
-- Walter Reisch

[Bartc]

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:g7**********@canopus.cc.umanitoba.ca...

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>>On 8 Aug 2008 at 15:02, sh******@gmail.com wrote:

>>There is, of course, but the people here will swear blind it doesn't
exist with all the fervor of a madman claiming the sky is not blue.

There are a lot of times that the sky is not blue. Like when it is
night out. Or when there are heavy clouds. Severe weather such as
close approximations of torados can turn the sky *very* strange
colors -- as can some kinds of severe snow storms.

"the sky is blue" is not a portable assumption.

So what colour is 'sky blue'?

--
Bartc

[santosh]

Bartc wrote:

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote:

<snip>

>"the sky is blue" is not a portable assumption.

So what colour is 'sky blue'?

It's implementation defined!

[Serve Lau]

<sh******@gmail.comschreef in bericht
news:9c**********************************@a3g2000p rm.googlegroups.com...

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.

You dont have to. You can store the number of allocated bytes without have
to introduce a new type. Write your own wrapper around malloc with the added
bonus that you can catch the implementation defined behaviour of malloc(0)
and store the size there. Something like the following but note that this
code doesnt take alignment issues into consideration.

void *my_alloc(size_t n) {
void *pv = 0;

if (n 0) {
if ((pv = malloc(n + sizeof(size_t))) != 0)
*(size_t *)pv = n;
}

return (pv != 0 ? ((size_t *)pv) + 1 : 0);
}

size_t memorysize(void *pv) {
return (pv != 0 ? *((size_t *)pv - 1) : 0);
}

size_t my_free(void *pv) {
size_t n = 0;

if (pv != 0) {
n = memorysize(pv);

free((size_t *)pv - 1);
}

return n;
}

[Ben Bacarisse]

"Serve Lau" <ni***@qinqin.comwrites:

<sh******@gmail.comschreef in bericht
news:9c**********************************@a3g2000p rm.googlegroups.com...

>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.

You dont have to. You can store the number of allocated bytes without
have to introduce a new type.

<snip>

void *my_alloc(size_t n) {
void *pv = 0;

if (n 0) {
if ((pv = malloc(n + sizeof(size_t))) != 0)
*(size_t *)pv = n;
}

return (pv != 0 ? ((size_t *)pv) + 1 : 0);
}

This can spoil the alignment that malloc has worked hard to ensure. I
think it is better to store the size at the end and I'd memcpy(endp,
&n, sizeof n) that data so as not to worry about alignment of the
size.

--
Ben.

[Ian Collins]

Ben Bacarisse wrote:

"Serve Lau" <ni***@qinqin.comwrites:

>void *my_alloc(size_t n) {
void *pv = 0;

if (n 0) {
if ((pv = malloc(n + sizeof(size_t))) != 0)
*(size_t *)pv = n;
}

return (pv != 0 ? ((size_t *)pv) + 1 : 0);
}

This can spoil the alignment that malloc has worked hard to ensure. I
think it is better to store the size at the end and I'd memcpy(endp,
&n, sizeof n) that data so as not to worry about alignment of the
size.

If you store the size at the end, how do you know where to look for it
on free?

--
Ian Collins.

[Ben Bacarisse]

Ian Collins <ia******@hotmail.comwrites:

Ben Bacarisse wrote:

>"Serve Lau" <ni***@qinqin.comwrites:

>>void *my_alloc(size_t n) {
void *pv = 0;

if (n 0) {
if ((pv = malloc(n + sizeof(size_t))) != 0)
*(size_t *)pv = n;
}

return (pv != 0 ? ((size_t *)pv) + 1 : 0);
}

This can spoil the alignment that malloc has worked hard to ensure. I
think it is better to store the size at the end and I'd memcpy(endp,
&n, sizeof n) that data so as not to worry about alignment of the
size.

If you store the size at the end, how do you know where to look for it
on free?

Duh! Pointless!

At least the post had one reasonable point in it (abut the alignment).

--
Ben.

[Ian Collins]

Ben Bacarisse wrote:

Ian Collins <ia******@hotmail.comwrites:

>Ben Bacarisse wrote:

>>This can spoil the alignment that malloc has worked hard to ensure. I
think it is better to store the size at the end and I'd memcpy(endp,
&n, sizeof n) that data so as not to worry about alignment of the
size.

If you store the size at the end, how do you know where to look for it
on free?

Duh! Pointless!

At least the post had one reasonable point in it (abut the alignment).

True! I usually pick the alignment that matches the machine.

This is generally the lowest multiple of the alignment of long long
greater or equal to the alignment of long double.

--
Ian Collins.

[Default User]

Ian Collins wrote:

Ben Bacarisse wrote:

This can spoil the alignment that malloc has worked hard to ensure.
I think it is better to store the size at the end and I'd
memcpy(endp, &n, sizeof n) that data so as not to worry about
alignment of the size.

If you store the size at the end, how do you know where to look for it
on free?

Just store the size somewhere, then move to the end of the block and
retrieve the size. Wait.


Brian

[santosh]

Ian Collins wrote:

Ben Bacarisse wrote:

>Ian Collins <ia******@hotmail.comwrites:

>>Ben Bacarisse wrote:

>>>This can spoil the alignment that malloc has worked hard to ensure.
I think it is better to store the size at the end and I'd
memcpy(endp, &n, sizeof n) that data so as not to worry about
alignment of the size.

If you store the size at the end, how do you know where to look for
it on free?

Duh! Pointless!

At least the post had one reasonable point in it (abut the
alignment).

True! I usually pick the alignment that matches the machine.

This is generally the lowest multiple of the alignment of long long
greater or equal to the alignment of long double.

I'd probably maintain separate lists for this. On modern processors I
doubt that this overhead matters at all.

[Barry Schwarz]

On Fri, 8 Aug 2008 20:22:37 +0200, "Serve Lau" <ni***@qinqin.com>
wrote:

>
<sh******@gmail.comschreef in bericht
news:9c**********************************@a3g2000 prm.googlegroups.com...

>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.

You dont have to. You can store the number of allocated bytes without have
to introduce a new type. Write your own wrapper around malloc with the added
bonus that you can catch the implementation defined behaviour of malloc(0)
and store the size there. Something like the following but note that this
code doesnt take alignment issues into consideration.

void *my_alloc(size_t n) {
void *pv = 0;

if (n 0) {
if ((pv = malloc(n + sizeof(size_t))) != 0)
*(size_t *)pv = n;
}

return (pv != 0 ? ((size_t *)pv) + 1 : 0);

The return value from malloc is guaranteed to be properly aligned for
any object type. Adding sizeof(size_t) bytes to this value is not
guaranteed to preserve this attribute. Consider the situation where
double requires 8-byte alignment and size_t is a typedef for a 4 byte
unsigned int.

>}

size_t memorysize(void *pv) {
return (pv != 0 ? *((size_t *)pv - 1) : 0);
}

This hardly seems worth having a function for. Why not just
substitute the "true expression" for the function call below.

>
size_t my_free(void *pv) {
size_t n = 0;

if (pv != 0) {
n = memorysize(pv);

free((size_t *)pv - 1);
}

return n;
}

--
Remove del for email

[Ian Collins]

Barry Schwarz wrote:

On Fri, 8 Aug 2008 20:22:37 +0200, "Serve Lau" <ni***@qinqin.com>
wrote:

>>
void *my_alloc(size_t n) {
void *pv = 0;

if (n 0) {
if ((pv = malloc(n + sizeof(size_t))) != 0)
*(size_t *)pv = n;
}

return (pv != 0 ? ((size_t *)pv) + 1 : 0);

The return value from malloc is guaranteed to be properly aligned for
any object type. Adding sizeof(size_t) bytes to this value is not
guaranteed to preserve this attribute. Consider the situation where
double requires 8-byte alignment and size_t is a typedef for a 4 byte
unsigned int.

Didn't we just have that conversation up-thread?

>size_t memorysize(void *pv) {
return (pv != 0 ? *((size_t *)pv - 1) : 0);
}

This hardly seems worth having a function for. Why not just
substitute the "true expression" for the function call below.

Clarity? Any compiler worth installing will inline such a trivial
function away.

--
Ian Collins.

[santosh]

Ian Collins wrote:

Barry Schwarz wrote:

>On Fri, 8 Aug 2008 20:22:37 +0200, "Serve Lau" <ni***@qinqin.com>
wrote:

>>>
void *my_alloc(size_t n) {
void *pv = 0;

if (n 0) {
if ((pv = malloc(n + sizeof(size_t))) != 0)
*(size_t *)pv = n;
}

return (pv != 0 ? ((size_t *)pv) + 1 : 0);

The return value from malloc is guaranteed to be properly aligned for
any object type. Adding sizeof(size_t) bytes to this value is not
guaranteed to preserve this attribute. Consider the situation where
double requires 8-byte alignment and size_t is a typedef for a 4 byte
unsigned int.

Didn't we just have that conversation up-thread?

>>size_t memorysize(void *pv) {
return (pv != 0 ? *((size_t *)pv - 1) : 0);
}

This hardly seems worth having a function for. Why not just
substitute the "true expression" for the function call below.

Clarity? Any compiler worth installing will inline such a trivial
function away.

Not if it were only in object code form, as a pre-built library.

[Ian Collins]

Barry Schwarz wrote:

On Sat, 09 Aug 2008 16:07:32 +1200, Ian Collins wrote:

>Clarity? Any compiler worth installing will inline such a trivial
function away.

I wonder how that works. The function wasn't declared static and is
therefore external. How does the compiler know the function isn't
called from another translation unit? If it can't know this, doesn't
it have to make the function available and assume it might be called.

That doesn't stop it being inlined at the point of the call.

--
Ian Collins.

[Johannes Bauer]

Barry Schwarz schrieb:

I wonder how that works. The function wasn't declared static and is
therefore external. How does the compiler know the function isn't
called from another translation unit? If it can't know this, doesn't
it have to make the function available and assume it might be called.

The point was to make the function external, not static, so the user
could call it from anywhere.

Regards,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electronics <47***********************@news.freenet.de>

[Ben Bacarisse]

Barry Schwarz <sc******@dqel.comwrites:

On Fri, 8 Aug 2008 20:22:37 +0200, "Serve Lau" <ni***@qinqin.com>
wrote:

>>size_t memorysize(void *pv) {
return (pv != 0 ? *((size_t *)pv - 1) : 0);
}

This hardly seems worth having a function for. Why not just
substitute the "true expression" for the function call below.

I would not make the size or complexity of the body the main
criterion for function-hood. While I would not write:

size_t halve(size_t x) { return x/2; }

I might write:

size_t get_parent_index(size_t idx) { return idx/2; }

in an array-based heap implementation.

--
Ben.

[Serve Lau]

"Barry Schwarz" <sc******@dqel.comschreef in bericht
news:3p********************************@4ax.com...

On Fri, 8 Aug 2008 20:22:37 +0200, "Serve Lau" <ni***@qinqin.com>
wrote:

>>
<sh******@gmail.comschreef in bericht
news:9c**********************************@a3g200 0prm.googlegroups.com...

>>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.

You dont have to. You can store the number of allocated bytes without have
to introduce a new type. Write your own wrapper around malloc with the
added
bonus that you can catch the implementation defined behaviour of malloc(0)
and store the size there. Something like the following but note that this
code doesnt take alignment issues into consideration.

void *my_alloc(size_t n) {
void *pv = 0;

if (n 0) {
if ((pv = malloc(n + sizeof(size_t))) != 0)
*(size_t *)pv = n;
}

return (pv != 0 ? ((size_t *)pv) + 1 : 0);

The return value from malloc is guaranteed to be properly aligned for
any object type. Adding sizeof(size_t) bytes to this value is not
guaranteed to preserve this attribute. Consider the situation where
double requires 8-byte alignment and size_t is a typedef for a 4 byte
unsigned int.

>>}

size_t memorysize(void *pv) {
return (pv != 0 ? *((size_t *)pv - 1) : 0);
}

This hardly seems worth having a function for. Why not just
substitute the "true expression" for the function call below.

Thats a design choice. I can imagine that one could need the memorysize
functionality at some point for debugging purposes to display the size of
all memory blocks allocated or something and putting this in a function also
hides the implementation detail that the first sizeof(size_t) bytes hold the
allocated memory size.

[CBFalconer]

Ben Bacarisse wrote:

>

.... snip ...

>
I would not make the size or complexity of the body the main
criterion for function-hood. While I would not write:

size_t halve(size_t x) { return x/2; }

I might write:

size_t get_parent_index(size_t idx) { return idx/2; }

in an array-based heap implementation.

How about:
"inline size_t get_parent_index(size_t idx) {return idx/2;}"

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Serve Lau]

"CBFalconer" <cb********@yahoo.comschreef in bericht
news:48***************@yahoo.com...

How about:
"inline size_t get_parent_index(size_t idx) {return idx/2;}"

its not certain that this will get inlined in the case of when the function
is external as discussed elsethread. If you want certainty use a macro. Or
as I've seen in some linux code, add the full function to a header and make
it static:

static inline size_t get_parent_index(size_t idx) {return idx/2;}

[Joe Wright]

sh******@gmail.com wrote:

is there any way to find out number of bytes freed on a particular
free() call in C

Sorry I'm late.

Short answer is no, you can't. Given 'char *lin = malloc(100);' can you
tell how many bytes are allocated? If lin == NULL the answer is zero,
otherwise 'at least 100'.

A successful malloc() call will 'allocate' the requested number of bytes
plus however many necessary to maintain the system. You cannot know the
total memory usage.

So, how many bytes will free() free? All of them.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Barry Schwarz]

On Sat, 09 Aug 2008 19:35:40 +1200, Ian Collins <ia******@hotmail.com>
wrote:

>Barry Schwarz wrote:

>On Sat, 09 Aug 2008 16:07:32 +1200, Ian Collins wrote:

>>Clarity? Any compiler worth installing will inline such a trivial
function away.

I wonder how that works. The function wasn't declared static and is
therefore external. How does the compiler know the function isn't
called from another translation unit? If it can't know this, doesn't
it have to make the function available and assume it might be called.

That doesn't stop it being inlined at the point of the call.

Does this mean that the code for the function will appear once in the
object module as a "stand alone" function and then again as often as
necessary inline at each point of invocation?

--
Remove del for email

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sat, 09 Aug 2008 15:17:45 -0700, Barry Schwarz wrote:

On Sat, 09 Aug 2008 19:35:40 +1200, Ian Collins <ia******@hotmail.com>
wrote:

>>Barry Schwarz wrote:

>>On Sat, 09 Aug 2008 16:07:32 +1200, Ian Collins wrote:

>>>Clarity? Any compiler worth installing will inline such a trivial
function away.

I wonder how that works. The function wasn't declared static and is
therefore external. How does the compiler know the function isn't
called from another translation unit? If it can't know this, doesn't
it have to make the function available and assume it might be called.

That doesn't stop it being inlined at the point of the call.

Does this mean that the code for the function will appear once in the
object module as a "stand alone" function and then again as often as
necessary inline at each point of invocation?

Essentially, yes. If it turns out the "stand alone" function is never
called, if all calls are inlined, the linker can and probably will remove
it afterwards.

[Ian Collins]

Barry Schwarz wrote:

On Sat, 09 Aug 2008 19:35:40 +1200, Ian Collins <ia******@hotmail.com>
wrote:

>Barry Schwarz wrote:

>>On Sat, 09 Aug 2008 16:07:32 +1200, Ian Collins wrote:
Clarity? Any compiler worth installing will inline such a trivial
function away.
I wonder how that works. The function wasn't declared static and is
therefore external. How does the compiler know the function isn't
called from another translation unit? If it can't know this, doesn't
it have to make the function available and assume it might be called.

That doesn't stop it being inlined at the point of the call.

Does this mean that the code for the function will appear once in the
object module as a "stand alone" function and then again as often as
necessary inline at each point of invocation?

As Harald said, yes. The code must be there in case the function is
used in another compilation unit.

--
Ian Collins.

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Ben Bacarisse wrote:
... snip ...

>>
I would not make the size or complexity of the body the main
criterion for function-hood. While I would not write:

size_t halve(size_t x) { return x/2; }

I might write:

size_t get_parent_index(size_t idx) { return idx/2; }

in an array-based heap implementation.

How about:
"inline size_t get_parent_index(size_t idx) {return idx/2;}"

How about ``syntax error before "size_t"'' if your (pre-C99) compiler
doesn't recognize the "inline" keyword?

Yes, most pre-C99 compilers probably do support inline as an extension
(and of course any C99 compiler must support it), but just the other
day you told somebody that he *must* place all his declarations before
statements in a block.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"

[Ian Collins]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

>Ben Bacarisse wrote:
... snip ...

>>I would not make the size or complexity of the body the main
criterion for function-hood. While I would not write:

size_t halve(size_t x) { return x/2; }

I might write:

size_t get_parent_index(size_t idx) { return idx/2; }

in an array-based heap implementation.

How about:
"inline size_t get_parent_index(size_t idx) {return idx/2;}"

How about ``syntax error before "size_t"'' if your (pre-C99) compiler
doesn't recognize the "inline" keyword?

Yes, most pre-C99 compilers probably do support inline as an extension
(and of course any C99 compiler must support it), but just the other
day you told somebody that he *must* place all his declarations before
statements in a block.

And most, if not all, c99 compilers would inline the function whether or
not the "inline" keyword was present.

--
Ian Collins.

[CBFalconer]

Ian Collins wrote:

>

.... snip ...

>
And most, if not all, c99 compilers would inline the function
whether or not the "inline" keyword was present.

Oh? Is that legal?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Ian Collins]

CBFalconer wrote:

Ian Collins wrote:
.... snip ...

>And most, if not all, c99 compilers would inline the function
whether or not the "inline" keyword was present.

Oh? Is that legal?

Can you either cite a reference where it's disallowed or a reason why it
shouldn't be legal?

--
Ian Collins.

[santosh]

CBFalconer wrote:

Ian Collins wrote:

>>

... snip ...

>>
And most, if not all, c99 compilers would inline the function
whether or not the "inline" keyword was present.

Oh? Is that legal?

With the provision of the "as if" rule, it is. The compiler can
*anything* it wants, provided the semantics of the C abstract machine
are respected (in conforming mode of course), and a conforming program
cannot detect such gyrations. Inlining a function in C90 mode is one
such example. If the address of the function is taken or if it is not
declared static, then a complete copy of the function image will also
be introduced into the object file.

[Richard]

CBFalconer <cb********@yahoo.comwrites:

Ian Collins wrote:

>>

... snip ...

>>
And most, if not all, c99 compilers would inline the function
whether or not the "inline" keyword was present.

Oh? Is that legal?

Why shouldn't it be? You keep crying about how there is no stack in the
standards - why on earth shouldn't the compiler inline ALL functions if
it so chose?

[Chris M. Thomasson]

"Ian Collins" <ia******@hotmail.comwrote in message
news:6g*************@mid.individual.net...

Ben Bacarisse wrote:

>Ian Collins <ia******@hotmail.comwrites:

>>Ben Bacarisse wrote:

>>>This can spoil the alignment that malloc has worked hard to ensure. I
think it is better to store the size at the end and I'd memcpy(endp,
&n, sizeof n) that data so as not to worry about alignment of the
size.

If you store the size at the end, how do you know where to look for it
on free?

Duh! Pointless!

At least the post had one reasonable point in it (abut the alignment).

True! I usually pick the alignment that matches the machine.

This is generally the lowest multiple of the alignment of long long
greater or equal to the alignment of long double.

FWIW, here is how I "attempt" to detect "smallest" maximum alignment;
welcome to hack world!:

http://groups.google.com/group/comp....7e0d0e97c5e1d9

http://groups.google.com/group/comp....c4da438e08028b

The offsetof macro-function works perfectly within this particular
approach...
Any thoughts? Can I improve the technique?

;^/

[vippstar]

On Aug 10, 2:21 pm, "Chris M. Thomasson" <[e-mail]:
<snip>

FWIW, here is how I "attempt" to detect "smallest" maximum alignment;
welcome to hack world!:

http://groups.google.com/group/comp....7e0d0e97c5e1d9

That code doesn't work.

from that post:

unsigned char* rawbuf[(SUPERBLOCK_SIZE * 2) - 1];

(Where SUPERBLOCKSIZE is 4096 * 8)
It exceeds environmental limits, thus all compilers can refuse to
compile it.

<snip>