malloc and free

[Dan Pop]

fyi;
bash-2.05b$ ./main 1
p[-2] = 4294967295
p[-1] = 4294967295

bash-2.05b$ ./main 5
p[-2] = 0
p[-1] = 0





That' not a lot of information.
Would you care to elaborate a little?

Just seems that my computer behaves diffrently than yours
(Running NetBSD on x86 btw)

Which compiler?

This is a library issue, idiot!

Dan

 

[E. Robert Tisdale]

I see no point in making assumptions about the OP's intentions and
denying him a sensible answer based on these assumptions.

I agree.
Answers should be straight forward.
Mysterious riddles are not usually helpful.

 

[Default User]

In <[email protected]> "Default User"


I see no point in making assumptions about the OP's intentions and
denying him a sensible answer based on these assumptions.

But there is no sensible answer to this, other than,
"implementation-defined".

You can give whatever answers you like to the question. There was
nothing wrong with mine, given the lack of details. Answer it yourself,
or don't, I don't care. I stand by mine. If you don't like, tough.




Brian Rodenborn

 

[Default User]

In <[email protected]> "Default User"


I see no point in making assumptions about the OP's intentions and
denying him a sensible answer based on these assumptions.

But there is no sensible answer to this, other than,
"implementation-specific".

You can give whatever answers you like to the question. There was
nothing wrong with mine, given the lack of details. Answer it yourself,
or don't, I don't care. I stand by mine. If you don't like, tough.




Brian Rodenborn

 

[E. Robert Tisdale]

But there is no sensible answer to this, other than,
"implementation-specific".

You are entitled to your opinion.

You can give whatever answers you like to the question.
There was nothing wrong with mine, given the lack of details.
Answer it yourself. Or don't. I don't care.
I stand by mine. If you don't like [it], tough.

Ed asked,
"When free() is used to free the memory allocated by malloc(),
how does it know the size of the memory to be freed?"
You answered, "Magic."

Ed asked,
"I guess I'm asking where does the info [get] stored?"
You answered,
"Someplace secret. None of your business, seriously.
How a particular implementation does it is highly platform-specific
and of little or no use to the programmer."

Do you really think this was helpful?

I expect students to be skeptical
and I think that they deserve, at least, a plausible explanation
of how such things might be implemented.

I think that you should familiarize yourself
with the notion of a "typical implementation"
if you want to help people learn
the C computer programming language.

 

[Default User]

E. Robert Tisdale wrote:

Ed asked,
"When free() is used to free the memory allocated by malloc(),
how does it know the size of the memory to be freed?"
You answered, "Magic."

I see you still haven't figured out how to use your killfile, huh
Trollsdale? Unless you were lying about trying.

At any rate, FOAD.



Brian Rodenborn

 

[Dan Pop]

But there is no sensible answer to this, other than,
"implementation-specific".

Wrong. After pointing out that the answer is implementation-specific,
one can elaborate on the most common solutions or post pointers to them.
At least two very reputable C books provide implementations that can be
studied by anyone interested.

It is a lot more helpful than saying "you don't need to know that".

Dan

 

[Michael Wojcik]

Obviously, malloc(size_t) stores the size somewhere
where free(void*) can find it.

This may be obvious, but it is not necessary, and there may be extant
conforming implementations where it is wrong, since there are
allocation schemes compatible with what the standard requires which
do not need to store the size passed to malloc.

If you'd care to do a bit of thinking and research, I bet you could
find one.

--
Michael Wojcik (e-mail address removed)

There are many definitions of what art is, but what I am convinced art is not
is self-expression. If I have an experience, it is not important because it
is mine. It is important because it's worth writing about for other people,
worth sharing with other people. That is what gives it validity. (Auden)

 

[Default User]

In <[email protected]> "Default User"


Wrong. After pointing out that the answer is implementation-specific,
one can elaborate on the most common solutions or post pointers to
them. At least two very reputable C books provide implementations
that can be studied by anyone interested.

You answer posts the way you want, and I'll answer them the way I want.
If you think it needs elaboration, go for it. I stand by my answer, I
think it is most appropriate for the given (lack) of information.

I don't consider this to be a factual matter, but a stylistic one, as
in "how much to read into this largely blank post".



Brian Rodenborn

 

[CBFalconer]

This may be obvious, but it is not necessary, and there may be
extant conforming implementations where it is wrong, since there
are allocation schemes compatible with what the standard
requires which do not need to store the size passed to malloc.

If you'd care to do a bit of thinking and research, I bet you
could find one.

I don't think he can handle the first part. One method would be to
have free be a null function, which would be perfectly satisfactory
in conjunction with an infinite memory supply. Just think, no more
worries about memory leaks!

In a more serious vein, some early Pascal (non-standard) systems
omitted dispose (the Pascal equivalent of free) and instead
supplied mark and release. mark marked the heap so that a
subsequent release could free everything allocated after that mark
was performed. It converted the heap into a second stack. It was
usable for a limited class of programs, including compilers. I
made the only implementation (known to me) that offered both
methods with intermixed operation.

 

[Jonathan Adams]

This may be obvious, but it is not necessary, and there may be extant
conforming implementations where it is wrong, since there are
allocation schemes compatible with what the standard requires which
do not need to store the size passed to malloc.

A real-life example is libmtmalloc(3lib) on Solaris. It stores (right
before the address it hands out) a pointer to the metadata for the
allocation chunk the buffer is from. (it is a power-of-2
segmented-store allocator)

Cheers,
- jonathan

 

[Dan Pop]

You answer posts the way you want, and I'll answer them the way I want.

Which is quite different from what you claimed above, isn't it?

Dan

 

[Dan Pop]

I don't think he can handle the first part. One method would be to
have free be a null function, which would be perfectly satisfactory
in conjunction with an infinite memory supply. Just think, no more
worries about memory leaks!

It's possible even for less trivial implementations of free(), that use
a BSD-style implementation of malloc. From the address of the block,
free() can figure out the pool it belongs to and all the blocks in a pool
have the same size. No need to store any kind of "hidden" data in the
memory block itself. I wouldn't expect any real *production*
implementation not to use any kind of hidden data, for performance
reasons, but it can be done.

Dan

 

[Default User]

Dan Pop wrote:

Which is quite different from what you claimed above, isn't it?

Sorry, you took too long to reply. I'm ignoring any further comment
from you on this.



Brian