IS this a proper way of freeing memory with free()

[Raman]

Hi All,

Here is a small Code,

int main(void)
{
char *p=(char *) malloc(100);
strcpy(p,"Test1 234567890");
p=p+10;
free(p);
/*** Is here a memory Leak, because p is now
pointing 10 location past to the start of allocated memory
****/

/** some stuff with p again**/


}
Thanks and Regards,
Raman Chalotra

[Richard Heathfield]

Yevgen Muntyan said:

Richard Heathfield wrote:

<snip>

>>
I fail to see why:

p = ALLOC_A_THING(f oo);

is more convenient than:

p = malloc(sizeof *p);

You fail to see, I don't. I like ALLOC_A_THING because
it describes the intent and hides the actual memory
allocation.

No, it doesn't, at least no more than malloc does. And even if it did,
which it doesn't, you still don't need the cast.

How
about custom_allocato r_here() function?

Yeah, you wouldn't need a cast there either.

<snip>

>>Or

#define FOO_NEW() ((Foo*) malloc (sizeof (Foo))) // *must* cast here

Why? The cast doesn't do any good,

It saves your butt if you change type,

So let me get this straight - you're saying that if you're daft enough
to use the type in the sizeof, you have to write some otherwise
unnecessary code to give the compiler a fighting chance of warning you
about your daft decision, and only at the risk of suppressing another
warning about your daft decision? Yeah, that's true - constructing
daftness is not difficult in C, or in any language. So?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

Yevgen Muntyan said:

<snip>

It's easy to write lot of C code which is valid C++. You have to
apply casts to return value of malloc though.

It's *pointless* to write lots of C code which is valid C++. If you
can't take advantage of C++'s non-C features, why bother using it? And
if you can, then it's not compilable in C. And malloc makes for bad C++
programs, on the whole.

>>>2) C++ defines mechanisms to interface to C code that has been
compiled as C code.

>>And I am talking about compiling *C* code with *C++* compiler.

If you're compiling it with a C++ compiler, its C++ code. It may look
like C, it may also compile as C, but its C++, and probably badly
written C++ at that.

Okay, let's use this term: "C code which is intended to be compiled
both with C and C++ compilers".

Ah, you mean "bad code" (unless your name is P J Plauger, which it
isn't).

I mean "C code" by "C code", i.e.
the code which is C according to C standard and is compilable with
C compiler in conforming mode. Not sure it's strict enough, but hope
you get the idea (which you already got anyway, I believe).
And no, C code doesn't become C++ code because you feed it to g++,
even if C++ folks think it is :)

Right. Instead, if it's a *good* C program, it becomes a raw material
which the compiler uses to produce diagnostic messages. If it's a bad
or trivial C program, it might also be a valid C++ program. Such
multi-language programs are few and far between, but they do exist.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Bos]

Yevgen Muntyan <mu************ ****@tamu.eduwr ote:

Mark McIntyre wrote:

On Thu, 08 Feb 2007 13:14:44 -0600, in comp.lang.c , Yevgen Muntyan
<mu************ ****@tamu.eduwr ote:

Flash wrote

>1) In C++ there are better methods than using malloc to get memory

You lose compatibility with C then ;)

Yes, people who think C and C++ are compatible often do seem to prefer
sloppy ill-defined compatibility over formal but slightly harder to
use compatibility. Smiley noted.

It's easy to write lot of C code which is valid C++. You have to
apply casts to return value of malloc though.

That's what Mark said: sloppy.

Richard

[Richard Bos]

"matevzb" <ma*****@gmail. comwrote:

On Feb 8, 11:51 pm, CBFalconer <cbfalco...@yah oo.comwrote:

matevzb wrote:

I tend to disagree on this one. If you change the type of "ptr"
you *should* examine *all* the places where "ptr" was used anyhow
(not just the line with malloc). If you don't, that's promoting
bad habits and that may bite harder than the x*sizeof(<type> ). I
personally always use the latter and have never had any trouble
with it.

Not necessary. If you have avoided unnecessary casts, the compiler
will point out any harmful type mismatches.

No, it won't in case of void *. A hypothetical case:
#include <stdlib.h>
#include <string.h>

typedef enum
{
SHORT = 0,
LONG = 1
} mytype;

int
fcn (void *array, mytype type, size_t size)
{
void *ptr;

switch (type)
{
case SHORT:
ptr = malloc (size * sizeof(short));

You didn't read the construct you're criticising, did you? You didn't
even read the reason why that construct is better, because here you're
demonstrating exactly why it is better than this code.

Again:

ptr=malloc(num * sizeof *ptr);

is always less likely to break than

ptr=malloc(num * sizeof(type));

If you choose to break that by using void * for everything and then
casting to random types, that's your problem, and it demonstrates
exactly nothing about the need to check anything in well-written C.

Richard

[Ian Collins]

Richard Heathfield wrote:

Yevgen Muntyan said:

<snip>

>>It's easy to write lot of C code which is valid C++. You have to
apply casts to return value of malloc though.

It's *pointless* to write lots of C code which is valid C++. If you
can't take advantage of C++'s non-C features, why bother using it? And
if you can, then it's not compilable in C. And malloc makes for bad C++
programs, on the whole.

It's not pointless if you are using C++ for hardware simulations to test
your C drivers.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>Yevgen Muntyan said:

<snip>

>>>It's easy to write lot of C code which is valid C++. You have to
apply casts to return value of malloc though.

It's *pointless* to write lots of C code which is valid C++. If you
can't take advantage of C++'s non-C features, why bother using it?
And if you can, then it's not compilable in C. And malloc makes for
bad C++ programs, on the whole.

It's not pointless if you are using C++ for hardware simulations to
test your C drivers.

If you're using C++ for the hardware simulations, you're using C++, not
C.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

>>Richard Heathfield wrote:

>>>Yevgen Muntyan said:

<snip>

It's easy to write lot of C code which is valid C++. You have to
apply casts to return value of malloc though.
It's *pointless* to write lots of C code which is valid C++. If you
can't take advantage of C++'s non-C features, why bother using it?
And if you can, then it's not compilable in C. And malloc makes for
bad C++ programs, on the whole.

It's not pointless if you are using C++ for hardware simulations to
test your C drivers.

If you're using C++ for the hardware simulations, you're using C++, not
C.

The driver code is C.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>Ian Collins said:

>>>Richard Heathfield wrote:
Yevgen Muntyan said:

>It's easy to write lot of C code which is valid C++. You have to
>apply casts to return value of malloc though.

It's *pointless* to write lots of C code which is valid C++. [...]

It's not pointless if you are using C++ for hardware simulations to
test your C drivers.

If you're using C++ for the hardware simulations, you're using C++,
not C.

The driver code is C.

Fine, in which case it isn't C++, so you don't need the cast on malloc.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[matevzb]

On Feb 9, 5:39 am, "Bill Pursell" <bill.purs...@g mail.comwrote:

On Feb 9, 1:11 am, "matevzb" <mate...@gmail. comwrote:

On Feb 8, 11:51 pm, CBFalconer <cbfalco...@yah oo.comwrote:mat evzb wrote:

I tend to disagree on this one. If you change the type of "ptr"
you *should* examine *all* the places where "ptr" was used anyhow
(not just the line with malloc). If you don't, that's promoting
bad habits and that may bite harder than the x*sizeof(<type> ). I
personally always use the latter and have never had any trouble
with it.

Not necessary. If you have avoided unnecessary casts, the compiler
will point out any harmful type mismatches.

No, it won't in case of void *. A hypothetical case:
#include <stdlib.h>
#include <string.h>

typedef enum
{
SHORT = 0,
LONG = 1
} mytype;

int
fcn (void *array, mytype type, size_t size)
{
void *ptr;

switch (type)
{
case SHORT:
ptr = malloc (size * sizeof(short));
memcpy (ptr, array, size * sizeof(short));
break;

case LONG:
ptr = malloc (size * sizeof(long));
memcpy (ptr, array, size * sizeof(long));
break;

default:
return -1;
}

return 0;
}

int
main (void)
{
long *ptr = malloc (10 * sizeof *ptr);

memset (ptr, 1, 10 * sizeof *ptr);
fcn (ptr, LONG, 10);

return 0;
}

If "ptr" in main() is changed from "long *" to "short *", there will
be no warning (and no casts were used). There will be a bug lurking
however.

This bug is caused by a design flaw in fcn. Change the
prototype so that the call is fcn(ptr, sizeof *ptr, 10) and
the problem is gone. Be in the habit of casting malloc
and hand editing your entire code base whenever you
change a type, and you will probably not notice the
design flaw. Be in the habit of not casting malloc and
not editing your code base regularly, and the design
flaw will be obvious early.

You could put it that way. Unfortunately, I have to use a function
very similar to the abovementioned fcn() and it's part of an external
library on which I have no influence whatsoever (the function is used
for packing parameters for RPC calls). I don't use any unnecessary
casts, but using sizeof *ptr brings me no benefits. Perhaps it's a
design flaw, but I prefer to call it reality.
--
WYCIWYG - what you C is what you get

[matevzb]

On Feb 9, 8:27 am, [e-mail] (Richard Bos) wrote:

"matevzb" <mate...@gmail. comwrote:

On Feb 8, 11:51 pm, CBFalconer <cbfalco...@yah oo.comwrote:

matevzb wrote:
I tend to disagree on this one. If you change the type of "ptr"
you *should* examine *all* the places where "ptr" was used anyhow
(not just the line with malloc). If you don't, that's promoting
bad habits and that may bite harder than the x*sizeof(<type> ). I
personally always use the latter and have never had any trouble
with it.

Not necessary. If you have avoided unnecessary casts, the compiler
will point out any harmful type mismatches.

No, it won't in case of void *. A hypothetical case:
#include <stdlib.h>
#include <string.h>

typedef enum
{
SHORT = 0,
LONG = 1
} mytype;

int
fcn (void *array, mytype type, size_t size)
{
void *ptr;

switch (type)
{
case SHORT:
ptr = malloc (size * sizeof(short));

You didn't read the construct you're criticising, did you? You didn't
even read the reason why that construct is better, because here you're
demonstrating exactly why it is better than this code.

Again:

ptr=malloc(num * sizeof *ptr);

is always less likely to break than

ptr=malloc(num * sizeof(type));

If you choose to break that by using void * for everything and then
casting to random types, that's your problem, and it demonstrates
exactly nothing about the need to check anything in well-written C.

It's not my choice, see the reply to Bill Pursell. And of course it's
my problem, I have to use such code, be it well-written C or not.
--
WYCIWYG - what you C is what you get