how to find number of bytes freed

[Ian Collins]

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?

 

[Ben Bacarisse]

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

 

[Ian Collins]

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.

 

[Default User]

Ben Bacarisse wrote:
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]

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]

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.

 

[Ian Collins]

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?

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.

 

[santosh]

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

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.

 

[Barry Schwarz]

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

Yes, I can see it now. Unfortunately, not all servers deliver the
messages in the same order or at the same time. teranews (which I
have the misfortune to use) has been known to hold outgoing messages
for three days before passing them to the usenet community.

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.

 

[Ian Collins]

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.

 

[Johannes Bauer]

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

 

[CBFalconer]

.... snip ...


Yes, I can see it now. Unfortunately, not all servers deliver the
messages in the same order or at the same time. teranews (which I
have the misfortune to use) has been known to hold outgoing messages
for three days before passing them to the usenet community.

When they recently combined that with a total blank-out recently, I
maneuvered a switch to motzarella. Also free. The pain is in
getting the message statuses correct. I used message various sorts
to do it, combined with a display in date order, but it is a major
pain when you don't do it at your suitable time.

Then motzarella had a blank-out! I switched back for a few days.

 

[Ben Bacarisse]

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.

 

[Serve Lau]

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.


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]

.... 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;}"

 

[Serve Lau]

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;}

 

[Barry Schwarz]

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?

 

[Harald van Dijk]

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]

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.

 

[Keith Thompson]

Ben Bacarisse wrote:
... snip ...

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.