would someone tell me:


s1: int *ptr = (int *) malloc (sizeof(int));

s2: int *ptr = (int *) malloc (n * sizeof(int));

when i use free(ptr),

what is the difference between the two statements?


thanks in advance.

Thomas Zhu wrote:
> would someone tell me:
>
>
> s1: int *ptr = (int *) malloc (sizeof(int));
>
> s2: int *ptr = (int *) malloc (n * sizeof(int));

  Please remove the cast. you don't need to cast the value returned by
malloc. Please include stdlib.h.

 The difference in the above two statements is the number of bytes
which are marked as reusable.

thanks.

but :

ptr = (int *) malloc (n * sizeof(int));
ptr ++;

free(ptr);

does the system free n mem-units or n-1 mem-units?

and why the cast is not necessary?

Le 21-10-2005, Thomas Zhu <zhuyin.nju@gmail.com> a �crit�:
> ptr = (int *) malloc (n * sizeof(int));
> ptr ++;
>
> free(ptr);
>
> does the system free n mem-units or n-1 mem-units?

  Neither one nor the other. This is UB.

> and why the cast is not necessary?

  Because malloc returns a void* pointer, and it
can be implicitely converted into int*. 

Marc Boyer

On Fri, 21 Oct 2005 09:37:34 +0000 (UTC),
    Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:


> Le 21-10-2005, Thomas Zhu <zhuyin.nju@gmail.com> a �crit�:
>> ptr = (int *) malloc (n * sizeof(int));
>> ptr ++;
>>
>> free(ptr);
>>
>> does the system free n mem-units or n-1 mem-units?
>
>   Neither one nor the other. This is UB.
>

In this case very likely a painfull UB.

In many implementations the size of an allocated buffer is stored
somwhere just before the buffer itself, and free finds that using a
negative offset from the passed pointer.  Obviously, if the ptr given
to free doesn't have the same value as returned from a call to malloc,
free can't find the size of the buffer and thus can't free it properly.

Villy

Thomas Zhu <zhuyin.nju@gmail.com> wrote:

> ptr = (int *) malloc (n * sizeof(int));
> ptr ++;

> free(ptr);

> does the system free n mem-units or n-1 mem-units?

Neither.  If you pass a pointer to free() that was not returned by a
call to malloc(), you get "undefined behavior" - in other words,
absolutely anything may happen at that point.

Furthermore, all you need to know about free() is that it deallocates
all the memory reserved by malloc(); that amount is at least, but by
no means limited to, the amount of memory you asked for.

-- 
Christopher Benson-Manica  | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org    | don't, I need to know.  Flames welcome.

I''ve got it!!!

I often heard some words (I dont know the their English name , i
translate them from my language to English):
1/memory leak
2/wild pointer

is there any good online books on them ?

thanks a lot.

Thomas Zhu a �crit :
> ptr = (int *) malloc (n * sizeof(int));

What are the words you don't understand in:

"Please remove the cast. you don't need to cast the value returned by 
malloc. Please include stdlib.h."

> ptr ++;
> 
> free(ptr);

Undefined behaviour.

The value passed to free() must exactly be the value received from malloc().

-- 
C is a sharp tool

Thanks a lot.

I've got it.
I supposed that the compiler would give a warning to the statement
without a cast.
But I was wrong.
Just now I tried some compilers, they all works.

Thomas Zhu a �crit :
> I often heard some words (I dont know the their English name , i
> translate them from my language to English):
> 1/memory leak

Meaning that some allocated memory can't be freed(). It may happen if 
you loose the value of the pointer.

    printf ("%p\n", (void *) malloc(123));

or more likely (Ok, strdup() not standard C but is POSIX.1, hence very 
portable)

    printf ("%s\n", strdup("Hello world"));

> 2/wild pointer

or 'dandling pointer'. An uninitialized pointer or a pointer to an 
invalid zone (out of the limits of an array for example). As long as you 
don't dereference it, it's fine (well, sort of). But if you dereference 
it, it bites (UB).

-- 
C is a sharp tool

Thomas Zhu, le 21/10/2005, a �crit :
> Thanks a lot.
>
> I've got it.
> I supposed that the compiler would give a warning to the statement
> without a cast.
> But I was wrong.
C++ give an error whithout the cast.
IMHO, it is not a mortal sin to cast the malloc() return in both C and 
C++.

-- 
Pierre Maurette

Pierre Maurette a �crit :
>> I supposed that the compiler would give a warning to the statement
>> without a cast.
>> But I was wrong.
> 
> C++ give an error whithout the cast.

Who cares... What is C++ ?

> IMHO, it is not a mortal sin to cast the malloc() return in both C and C++.

.... but is can hide some nasty bug, like to forget to include <stdlib.h>

-- 
C is a sharp tool

Pierre Maurette a �crit :
>> I supposed that the compiler would give a warning to the statement
>> without a cast.
>> But I was wrong.
> 
> C++ give an error whithout the cast.

Who cares... What is C++ ?

> IMHO, it is not a mortal sin to cast the malloc() return in both C and C++.

.... but it can hide some nasty bug, like to forget to include <stdlib.h>

-- 
C is a sharp tool

> and why the cast is not necessary?

Why is not needed, the cast is needed as pointer from void* to non-void 
requires an explicit cast.



"Thomas Zhu" <zhuyin.nju@gmail.com> wrote in message 
news:1129887444.076422.148700@g43g2000cwa.googlegroups.com...
> thanks.
>
> but :
>
> ptr = (int *) malloc (n * sizeof(int));
> ptr ++;
>
> free(ptr);
>
> does the system free n mem-units or n-1 mem-units?
>
> and why the cast is not necessary?
> 

TomHanks <gettechtips@yahoo.co.in> wrote:

> Why is not needed, the cast is needed as pointer from void* to non-void 
> requires an explicit cast.

Wrong.

-- 
Christopher Benson-Manica  | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org    | don't, I need to know.  Flames welcome.

Pierre Maurette wrote:

> Thomas Zhu, le 21/10/2005, a �crit :
> > Thanks a lot.
> > 
> > I've got it.
> > I supposed that the compiler would give a warning to the statement
> > without a cast.
> > But I was wrong.

> C++ give an error whithout the cast.

So? This is not C++;

> IMHO, it is not a mortal sin to cast the malloc() return in both C
> and C++.

You shouldn't be using malloc() in C++. You should be using new.
Writing code to be cross-language compatible is usually a waste of time
and inefficient, outside of a few library developers.


Brian

-- 
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

Thomas Zhu wrote:

> Thanks a lot.
> 
> I've got it.
> I supposed that the compiler would give a warning to the statement
> without a cast.
> But I was wrong.
> Just now I tried some compilers, they all works.

Please read my .sig.


Brian
-- 
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

Default User, le 21/10/2005, a �crit :
> Pierre Maurette wrote:
>
>> Thomas Zhu, le 21/10/2005, a �crit :
>>> Thanks a lot.
>>> 
>>> I've got it.
>>> I supposed that the compiler would give a warning to the statement
>>> without a cast.
>>> But I was wrong.
>
>> C++ give an error whithout the cast.
>
> So? This is not C++;
My english is so bad. I prefer to b concise. And you seem to need 
verbose mode:
Maybe
>> C++ give an error whithout the cast.
accounts for:
>>> I supposed that the compiler would give a warning to the statement
>>> without a cast.


>> IMHO, it is not a mortal sin to cast the malloc() return in both C
>> and C++.
>
> You shouldn't be using malloc() in C++. You should be using new.
> Writing code to be cross-language compatible is usually a waste of time
> and inefficient, outside of a few library developers.
Yes. It is not a good idea, unless whn it is.

-- 
Pierre Maurette

Pierre Maurette wrote:

> Default User, le 21/10/2005, a �crit :
> > Pierre Maurette wrote:
 
> > > C++ give an error whithout the cast.
> > 
> > So? This is not C++;
> My english is so bad. I prefer to b concise. 

Your English would improve automatically by not using strange
abreviations.

> And you seem to need verbose mode:  Maybe

"Maybe"? Maybe what? I certainly could use more verbosity here, as I
have no idea what you mean.

 
> > You shouldn't be using malloc() in C++. You should be using new.
> > Writing code to be cross-language compatible is usually a waste of
> > time and inefficient, outside of a few library developers.
> Yes. It is not a good idea, unless whn it is.

Well, that certainly covers it. 


Brian

-- 
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

Christopher Benson-Manica wrote:
> Thomas Zhu <zhuyin.nju@gmail.com> wrote:
> > does the system free n mem-units or n-1 mem-units?
>
> Neither.  If you pass a pointer to free() that was not returned by a
> call to malloc(), you get "undefined behavior" - in other words,
> absolutely anything may happen at that point.

Which techincally means that the implementation could free "n mem-units
or n-1 mem units". Not that you should rely on this behavior, but I
just want to point out on the broad abilities of a computer to do
mischief :).

On Fri, 21 Oct 2005 17:20:18 +0000, Default User wrote:
> Pierre Maurette wrote:
>> Default User, le 21/10/2005, a �crit :
>> > Pierre Maurette wrote:
>  
>> > > C++ give an error whithout the cast.
>> > 
>> > So? This is not C++;
>> My english is so bad. I prefer to b concise.
> 
> Your English would improve automatically by not using strange
> abreviations.
> 
>> And you seem to need verbose mode:  Maybe
> 
> "Maybe"? Maybe what? I certainly could use more verbosity here, as I
> have no idea what you mean.

You snipped the subsequent quotes to which "maybe" applied.  I believe
that what Pierre wrote translates to this:

Maybe the reason I wrote "C++ give an error whithout the cast." is because
the OP wrote "I supposed that the compiler would give a warning to the
statement without a cast."

i.e. he was informing the OP of an alternate situation in which the
supposition holds.

[...]
-- 
http://members.dodo.com.au/~netocrat

Razzer wrote:
> Christopher Benson-Manica wrote:
> 
>>Thomas Zhu <zhuyin.nju@gmail.com> wrote:
>>
>>>does the system free n mem-units or n-1 mem-units?
>>
>>Neither.  If you pass a pointer to free() that was not returned by a
>>call to malloc(), you get "undefined behavior" - in other words,
>>absolutely anything may happen at that point.
> 
> 
> Which techincally means that the implementation could free "n mem-units
> or n-1 mem units". Not that you should rely on this behavior, but I
> just want to point out on the broad abilities of a computer to do
> mischief :).
> 
Erm, more likely it would free an amount of storage that was not 
intended. Or crash. Or do things of which we shall not speak. Or 
*appear* to work -- at least until the worst possible moment.

Corruption can be like that.

Cheers,
--ag

-- 
Artie Gold -- Austin, Texas
http://goldsays.blogspot.com (new post 8/5)
http://www.cafepress.com/goldsays
"If you have nothing to hide, you're not trying!"

hi, would you please tell me, what is the meaing of (n * sizeof(int)).
is it means n times sizeof(int) or some pointer???

what is cast. would you please describe the whole question with answer
to me...Madhav.
as i'm new to the language.

ashu wrote:
> what is cast. would you please describe the whole question with answer
> to me...Madhav.
> as i'm new to the language.
> 
The cast is an explicit mechanism to force a type conversion. We won't 
describe the whole thing here. Look it up in your C book. If you don't 
have one, get one. This newsgroup is not a substitute for a C book.

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

"Default User" <defaultuserbr@yahoo.com> writes:

> Pierre Maurette wrote:
> 
> > Thomas Zhu, le 21/10/2005, a �crit :
> > > Thanks a lot.
> > > 
> > > I've got it.
> > > I supposed that the compiler would give a warning to the statement
> > > without a cast.
> > > But I was wrong.
> 
> > C++ give an error whithout the cast.
> 
> So? This is not C++;
> 
> > IMHO, it is not a mortal sin to cast the malloc() return in both C
> > and C++.
> 
> You shouldn't be using malloc() in C++. You should be using new.
> Writing code to be cross-language compatible is usually a waste of time
> and inefficient, outside of a few library developers.

No rule without exceptions...
Last week I used malloc in C++ for the first time in the 15 years I've
been playing with the language... I had a buffer which I needed to
shrink every once in a while, so I saved lots of CPU cycles switching
from new[] and delete[] to malloc, realloc and free.

IMHO opinion it is a mortal sin to use any cast at all when they are
not absolutely necessary, and a sin, but forgivable, to use casts 
where they are necessary. We are all sinners of course.

/Niklas Norrthon

Niklas Norrthon <do-not-use@invalid.net> a �crit�:
> "Default User" <defaultuserbr@yahoo.com> writes:
>> Pierre Maurette wrote:
>> > Thomas Zhu, le 21/10/2005, a �crit :
>> > > Thanks a lot.
>> > > 
>> > > I've got it.
>> > > I supposed that the compiler would give a warning to the statement
>> > > without a cast.
>> > > But I was wrong.
>> 
>> > C++ give an error whithout the cast.
>> 
>> So? This is not C++;
>> 
>> > IMHO, it is not a mortal sin to cast the malloc() return in both C
>> > and C++.
>> 
>> You shouldn't be using malloc() in C++. You should be using new.
>> Writing code to be cross-language compatible is usually a waste of time
>> and inefficient, outside of a few library developers.
>
> No rule without exceptions...
> Last week I used malloc in C++ for the first time in the 15 years I've
> been playing with the language... I had a buffer which I needed to
> shrink every once in a while, so I saved lots of CPU cycles switching
> from new[] and delete[] to malloc, realloc and free.

  Using a std::vector and resize was not adapted in your context ?

> IMHO opinion it is a mortal sin to use any cast at all when they are
> not absolutely necessary, and a sin, but forgivable, to use casts 
> where they are necessary. 

  As I often say 'follow this advice until you have a good
reason to do otherwise'.

Marc Boyer

Netocrat wrote:

> On Fri, 21 Oct 2005 17:20:18 +0000, Default User wrote:
> > Pierre Maurette wrote:
> >> Default User, le 21/10/2005, a �crit :
> >> > Pierre Maurette wrote:
> >  
> >> > > C++ give an error whithout the cast.
> >> > 
> >> > So? This is not C++;
> >> My english is so bad. I prefer to b concise.
> > 
> > Your English would improve automatically by not using strange
> > abreviations.
> > 
> >> And you seem to need verbose mode:  Maybe
> > 
> > "Maybe"? Maybe what? I certainly could use more verbosity here, as I
> > have no idea what you mean.
> 
> You snipped the subsequent quotes to which "maybe" applied.  I believe
> that what Pierre wrote translates to this:

I snipped nothing else that he wrote following that line. The only
thing following the "maybe" was some old quotes that he left in.


> Maybe the reason I wrote "C++ give an error whithout the cast." is
> because the OP wrote "I supposed that the compiler would give a
> warning to the statement without a cast."

You are inferring something from the word "maybe" and some unsnipped
quotes. As I said, he needed to say what he meant. I'm not a tea-leaf
reader (or old quote diviner).

> i.e. he was informing the OP of an alternate situation in which the
> supposition holds.

Nonsense. Complete supposition.




Brian

On Mon, 24 Oct 2005 17:28:06 +0000, Default User wrote:
> Netocrat wrote:
>> On Fri, 21 Oct 2005 17:20:18 +0000, Default User wrote:
>> > Pierre Maurette wrote:
>> >> Default User, le 21/10/2005, a �crit :
>> >> > Pierre Maurette wrote:
>> >  
>> >> > > C++ give an error whithout the cast.
>> >> > 
>> >> > So? This is not C++;
>> >> My english is so bad. I prefer to b concise.
>> > 
>> > Your English would improve automatically by not using strange
>> > abreviations.
>> > 
>> >> And you seem to need verbose mode:  Maybe
>> > 
>> > "Maybe"? Maybe what? I certainly could use more verbosity here, as I
>> > have no idea what you mean.
>> 
>> You snipped the subsequent quotes to which "maybe" applied.  I believe
>> that what Pierre wrote translates to this:
> 
> I snipped nothing else that he wrote following that line. The only
> thing following the "maybe" was some old quotes that he left in.

Those old quotes are the ones to which I referred.

>> Maybe the reason I wrote "C++ give an error whithout the cast." is
>> because the OP wrote "I supposed that the compiler would give a
>> warning to the statement without a cast."
> 
> You are inferring something from the word "maybe" and some unsnipped
> quotes. 

In the absence of mind-reading, inference is partly what communication is
about, no?

> As I said, he needed to say what he meant. I'm not a tea-leaf
> reader (or old quote diviner).

Right, I only stepped in because it was apparent his confidence in
his English skills prevented him from doing that to the point that you
could readily understand, however with a little interpretation his meaning
became clear to me.

>> i.e. he was informing the OP of an alternate situation in which the
>> supposition holds.
> 
> Nonsense. Complete supposition.

It's a supposition, but it does make sense - reread his post assuming that
"Maybe" had been followed by a colon as "accounts for" had.  Also note
that it appeared on a new line in the original whereas in your quoted
version "Maybe" appears on the same line as the preceding sentence.

-- 
http://members.dodo.com.au/~netocrat

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

> Niklas Norrthon <do-not-use@invalid.net> a �crit�:
> >
> > No rule without exceptions...
> > Last week I used malloc in C++ for the first time in the 15 years I've
> > been playing with the language... I had a buffer which I needed to
> > shrink every once in a while, so I saved lots of CPU cycles switching
> > from new[] and delete[] to malloc, realloc and free.
> 
>   Using a std::vector and resize was not adapted in your context ?

No, resize just erases the elements. It doesn't return anything to the
memory manager.

/Niklas Norrthon

Netocrat wrote:

 
> > I snipped nothing else that he wrote following that line. The only
> > thing following the "maybe" was some old quotes that he left in.
> 
> Those old quotes are the ones to which I referred.

There was no indication from new text that the old text was being
reiterated versus merely left behind. As the OP could barely write a
legible post, the second assumption is as valid as the first.

As I said, he needed more text to remove ambiguity.




-- 
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

On 2005-10-25, Niklas Norrthon <do-not-use@invalid.net> wrote:
> Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
>
>> Niklas Norrthon <do-not-use@invalid.net> a �crit�:
>> >
>> > No rule without exceptions...
>> > Last week I used malloc in C++ for the first time in the 15 years I've
>> > been playing with the language... I had a buffer which I needed to
>> > shrink every once in a while, so I saved lots of CPU cycles switching
>> > from new[] and delete[] to malloc, realloc and free.
>> 
>>   Using a std::vector and resize was not adapted in your context ?
>
> No, resize just erases the elements. It doesn't return anything
> to the memory manager.

In that case, you need the swap-shrink trick.

Assuming v is the vector of int you want to shrink:

  vector<int>(v).swap(v);

See URL:http://www.gotw.ca/gotw/054.htm.

-- 
Neil Cerutti

Default User wrote:
>
> As I said, he needed more text to remove ambiguity.
> 

Dude, are you parsing posts instead of reading?

Neil Cerutti wrote:
> On 2005-10-25, Niklas Norrthon <do-not-use@invalid.net> wrote:
> 
>>Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
>>
>>>Niklas Norrthon <do-not-use@invalid.net> a �crit :
>>>
>>>>No rule without exceptions...
>>>>Last week I used malloc in C++ for the first time in the 15 years I've
>>>>been playing with the language... I had a buffer which I needed to
>>>>shrink every once in a while, so I saved lots of CPU cycles switching
>>>>from new[] and delete[] to malloc, realloc and free.
>>>
>>>  Using a std::vector and resize was not adapted in your context ?
>>
>>No, resize just erases the elements. It doesn't return anything
>>to the memory manager.
> 
> In that case, you need the swap-shrink trick.
> 
> Assuming v is the vector of int you want to shrink:
> 
>   vector<int>(v).swap(v);
> 
> See URL:http://www.gotw.ca/gotw/054.htm.

Can you please take this discussion somewhere it is topical, such as 
comp.lang.c++

FU set
-- 
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

cappeca@godisdead.com wrote:

> Default User wrote:
> > 
> > As I said, he needed more text to remove ambiguity.
> > 
> 
> Dude, are you parsing posts instead of reading?


"Dude" I have no idea what you mean.



Brian

-- 
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.