Multiple malloc in the same pointer

[=?iso-8859-1?q?Andr=E9_Wagner?=]

Hello,

I'm using malloc several times in the same pointer, such as:

int i;
my_structure_t* my_structure

while(true)
{
my_structure = malloc(sizeof(my_structure_t));
printf("%d\n", my_structure);
}

But I'm finding out that, no matter how many times I call malloc in
the pointer, every time my pointer points to the same memory position.

Is this correct or am I speaking nonsense here? If I'm correct, how
can I do to allocate new memory on each call?

I'm using gcc on linux.

Regards,

André

[bert]

On 21 Aug, 14:14, André Wagner <[e-mail]:

Hello,

I'm using malloc several times in the same pointer, such as:

int i;
my_structure_t* my_structure

while(true)
{
my_structure = malloc(sizeof(my_structure_t));
printf("%d\n", my_structure);

}

But I'm finding out that, no matter how many times I call malloc in
the pointer, every time my pointer points to the same memory position.

Is this correct or am I speaking nonsense here? If I'm correct, how
can I do to allocate new memory on each call?

I'm using gcc on linux.

Regards,

André

You have promised printf() an integer, but
you are actually passing it a pointer.

It is quite plausible that all the pointers are
different, but whatever part of them printf()
is interpreting as an integer is the same.
--

[Mark Bluemel]

André Wagner wrote:

Hello,

I'm using malloc several times in the same pointer, such as:

Don't tell us "such as", show us the smallest self-contained program
which demonstrates the problem.

int i;
my_structure_t* my_structure

while(true)
{
my_structure = malloc(sizeof(my_structure_t));
printf("%d\n", my_structure);
}

%d is not the correct printf mask for a pointer (and I'm fairly sure
that it should be a void pointer that you pass to printf). Ignoring the
void pointer issue, if, for example, you have 64-bit pointers and 32-bit
ints, this would probably show the same value for the 32-bits of the
pointer that happened to be printed...

Correct the mask (and pass void *) for a start and then show us a
minimal program demonstrating the problem if it still seems wrong.

[=?iso-8859-1?q?Andr=E9_Wagner?=]

But I'm finding out that, no matter how many times I call malloc in

the pointer, every time my pointer points to the same memory position.

You have promised printf() an integer, but
you are actually passing it a pointer.

It is quite plausible that all the pointers are
different, but whatever part of them printf()
is interpreting as an integer is the same.

That was a good guess (I haven't thought of that) but I changed the %d
to %p, and still shows the same address.

André

[santosh]

André Wagner wrote:

Hello,

I'm using malloc several times in the same pointer, such as:

int i;
my_structure_t* my_structure

while(true)
{
my_structure = malloc(sizeof(my_structure_t));

Better might be:
my_structure = malloc(sizeof *my_structure);

printf("%d\n", my_structure);

Do:
printf("%p\n", (void *)my_structure);

And see again.

<snip>

[=?iso-8859-1?q?Andr=E9_Wagner?=]

I already found out, it was a bug in my program. I was freeing the
memory somewhere, so malloc was just taking the same memory position
over and over again.

I am sorry for the inconvenience.

André

On 21 ago, 10:29, André Wagner <[e-mail]:

But I'm finding out that, no matter how many times I call malloc in
the pointer, every time my pointer points to the same memory position.

You have promised printf() an integer, but
you are actually passing it a pointer.

It is quite plausible that all the pointers are
different, but whatever part of them printf()
is interpreting as an integer is the same.

That was a good guess (I haven't thought of that) but I changed the %d
to %p, and still shows the same address.

André

[Chris Dollin]

André Wagner wrote:

But I'm finding out that, no matter how many times I call malloc in
the pointer, every time my pointer points to the same memory position.

You have promised printf() an integer, but
you are actually passing it a pointer.

It is quite plausible that all the pointers are
different, but whatever part of them printf()
is interpreting as an integer is the same.

That was a good guess (I haven't thought of that) but I changed the %d
to %p, and still shows the same address.

Show us /the actual code/. If you don't understand what's going wrong,
you don't understand which bits matter, so you must show us /exactly/
what you wrote.

--
Chris "insert Narnia quote here" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Mark Bluemel]

André Wagner wrote:

>>But I'm finding out that, no matter how many times I call malloc in
the pointer, every time my pointer points to the same memory position.

You have promised printf() an integer, but
you are actually passing it a pointer.

It is quite plausible that all the pointers are
different, but whatever part of them printf()
is interpreting as an integer is the same.

That was a good guess (I haven't thought of that) but I changed the %d
to %p, and still shows the same address.

It didn't do that for a small test that I just ran. Show us some real
code which demonstrates the problem...

[Mark Bluemel]

André Wagner wrote:

I already found out, it was a bug in my program. I was freeing the
memory somewhere, so malloc was just taking the same memory position
over and over again.

So the code which showed the problem was not like the code you posted?

This shows why we keep asking for the smallest compilable program that
shows the problem -

1) in producing that program you'd very likely debug the issue anyway

2) if there is still a program, there's a chance we can find it, but
only with a real program not some vague hints at what the program may
(or may not) look like.

[Default User]

André Wagner wrote:

I already found out, it was a bug in my program.

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or:
<http://www.caliburn.nl/topposting.html>

[Old Wolf]

On Aug 22, 1:35 am, André Wagner <[e-mail]:

while(true)
{
my_structure = malloc(sizeof(my_structure_t));
printf("%d\n", my_structure);
}
I already found out, it was a bug in my program. I was freeing the
memory somewhere, so malloc was just taking the same memory position
over and over again.

Even if the code was as posted, you could still get the
same address every time, if the compiler is smart enough
to notice that the value of 'my_structure' is no longer
accessible after each loop iteration.

[Barry Schwarz]

On Tue, 21 Aug 2007 15:48:29 -0700, Old Wolf <ol*****@inspire.net.nz>
wrote:

>On Aug 22, 1:35 am, André Wagner <[e-mail]:

>while(true)
{
my_structure = malloc(sizeof(my_structure_t));
printf("%d\n", my_structure);
}
I already found out, it was a bug in my program. I was freeing the
memory somewhere, so malloc was just taking the same memory position
over and over again.

Even if the code was as posted, you could still get the
same address every time, if the compiler is smart enough
to notice that the value of 'my_structure' is no longer
accessible after each loop iteration.

That would seem to violate the requirement that allocated memory
remain allocated until explicitly freed. There doesn't seem to be an
exception for memory no longer accessed. Or would this be allowed
under the "as if" rule? But then, what about someone trying to test
if malloc really returns NULL on failure by repeatedly allocating
memory until he runs out?
Remove del for email

[Richard Tobin]

In article <gg********************************@4ax.com>,
Barry Schwarz <sc******@doezl.netwrote:

>That would seem to violate the requirement that allocated memory
remain allocated until explicitly freed. There doesn't seem to be an
exception for memory no longer accessed. Or would this be allowed
under the "as if" rule?

Yes, you can't tell whether it's still allocated. I suppose you could
argue that you *can* tell, because if it was still allocated you be
bound to run out of memory eventually, but I don't think it's the
intent of the standard to prevent optimisations that you can detect
because they make things run better.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.