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

[Yevgen Muntyan]

Richard Heathfield wrote:

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.

malloc(sizeof *ptr)

doesn't clearly state what it does. For you it does, you are used
to this construct and it's crystal clear to you. This is a style issue.
No less than

if (foo) {
do_something ();
}

vs

if (foo)
{
do_something ();
}

>

>How
about custom_allocato r_here() function?

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

Nah, tell how more convenient is

ptr = custom_allocato r_with_some_opt ions (sizeof *ptr, OPTIONS);

than

ptr = ALLOC_A_THING(T ype);

<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?

Sorry, which one? Again casting from int to pointer? Oh yeah, compilers
are not obliged by holy standard to emit warnings about missing
prototypes, bummer.

You think that

ptr = malloc (sizeof *ptr)

is a nice workaround for typeless return value of malloc, I don't. I
think

((Type*) malloc (sizeof (Type)))

is better because it has a type. And, say, I like g_new(Foo, 1) better
because it says "allocate one Foo structure".
I can do

return g_new(Foo, 1);

or

Foo *ptr = g_new (Foo, 1);

Anyway, here's another real piece of code:

http://svn.gnome.org/viewcvs/glib/tr....h?view=markup

You can claim how much you want that I am stupid, authors
of that code are stupid, that it's nice to use void* when you
allocate memory, but not everyone agrees with that. Now you can
repeat the killer argument about Elvis to complete proof
of you being right.

Yevgen

[Christopher Layne]

Yevgen Muntyan wrote:

malloc(sizeof *ptr)

doesn't clearly state what it does. For you it does, you are used
to this construct and it's crystal clear to you. This is a style issue.
No less than

Yes it does clearly state it. Go read up on the C language.

Nah, tell how more convenient is

ptr = custom_allocato r_with_some_opt ions (sizeof *ptr, OPTIONS);

than

ptr = ALLOC_A_THING(T ype);

ALLOC_A_THING() does not take options. They aren't even the same. You're
arguing specific purpose vs generic purpose. Go back and try again.

You think that

ptr = malloc (sizeof *ptr)

is a nice workaround for typeless return value of malloc, I don't. I
think

This is NOT a workaround. It has NOTHING to do with types. It has everything
to do with tying the size to the identifier itself and indirectly that size
being a *resultant value base on the identifier* which means you change
things in *one* place, not *two*.

((Type*) malloc (sizeof (Type)))

is better because it has a type. And, say, I like g_new(Foo, 1) better
because it says "allocate one Foo structure".
I can do

Please go read up on C again or something along those lines. You don't NEED to
cast the value returned. It does not do anything for the type, and providing
an actual type to sizeof does not influence malloc() in any way. malloc()
does not care about types! It allocates dynamic memory, that's it.

It seems at this point your insistance on the applicability of casting is
borne out of a refusal to perceive things in a different way than you have
trained yourself to do.

[Yevgen Muntyan]

Richard Heathfield wrote:

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.

It seems I forgot that you're talking here about strictly conforming
code here. Indeed, if you have a strictly conforming program then
you're limited to bunch of C files without any non-standard headers,
and any custom allocator business or libraries or anything like that
is out question. A header like

foo.h:

#define FOO_NEW() ...

simply can't be in a strictly conforming program and you use
only malloc(whatever ) (or calloc, etc.) in your code. Yes, using only
standard features promotes use of raw malloc, and yes, casting
raw malloc in regular code like

int func (..)
{
...
ptr = malloc (anything);
...
}

is not good.

Yevgen

[Yevgen Muntyan]

Christopher Layne wrote:

Yevgen Muntyan wrote:

>malloc(sizeo f *ptr)

doesn't clearly state what it does. For you it does, you are used
to this construct and it's crystal clear to you. This is a style issue.
No less than

Yes it does clearly state it. Go read up on the C language.

>Nah, tell how more convenient is

ptr = custom_allocato r_with_some_opt ions (sizeof *ptr, OPTIONS);

than

ptr = ALLOC_A_THING(T ype);

ALLOC_A_THING() does not take options. They aren't even the same. You're
arguing specific purpose vs generic purpose. Go back and try again.

>You think that

ptr = malloc (sizeof *ptr)

is a nice workaround for typeless return value of malloc, I don't. I
think

This is NOT a workaround. It has NOTHING to do with types. It has everything
to do with tying the size to the identifier itself and indirectly that size
being a *resultant value base on the identifier* which means you change
things in *one* place, not *two*.

>((Type*) malloc (sizeof (Type)))

is better because it has a type. And, say, I like g_new(Foo, 1) better
because it says "allocate one Foo structure".
I can do

Please go read up on C again or something along those lines. You don't NEED to
cast the value returned. It does not do anything for the type, and providing
an actual type to sizeof does not influence malloc() in any way. malloc()
does not care about types! It allocates dynamic memory, that's it.

Exactly, malloc is typeless. And it's good to wrap blind typeless malloc
into a macro which gets an expression which does have type. I NEED to
cast return value to get an expression with type, because I want that
expression to have type. I NEED an expression which reads "allocate one
Foo structure". I don't like an expression which reads "allocate
sizeof(the-type-of-this-pointer-dereferenced) bytes". I want compiler
to warn me if I assign that Foo* to a variable of wrong type or
return it from a function with different return type, or feed it to
a function with different type of argument.

It seems at this point your insistance on the applicability of casting is
borne out of a refusal to perceive things in a different way than you have
trained yourself to do.

I guess you're right here to some extent. Or maybe I refuse to do things
in a worse way than I do them now?

Yevgen

[Yevgen Muntyan]

Richard Bos wrote:

"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));

It's likely to break hard when ptr has different type from what
really needs to be allocated. And that happens (and you said "always").

If you choose to break that by using void * for everything and then
casting to random types, that's your problem,

No, it's your problem that you apply this kind of arguments like
"casting to random types", so that the guy you are replying to
sounds like an idiot which really casts stuff to random types.

Yevgen

[Christopher Layne]

Yevgen Muntyan wrote:

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

is always less likely to break than

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

It's likely to break hard when ptr has different type from what
really needs to be allocated. And that happens (and you said "always").

Which is more likely to happen with the second case. You're flip flopping
around here.

>If you choose to break that by using void * for everything and then
casting to random types, that's your problem,

No, it's your problem that you apply this kind of arguments like
"casting to random types", so that the guy you are replying to
sounds like an idiot which really casts stuff to random types.

Okay programmer insecurity counseling time.

[Christopher Layne]

Yevgen Muntyan wrote:

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

No. It's not. It's not clear, it's obtuse and pointless monkeying that
*reduces* visible intent.

What do you do if you need to replace malloc() with another allocator?
Grep? While this macro is indeed stupid, it was an example of where
cast is needed.
*If* you write a macro which allocates a Foo structure (this macro can
do arbitrary nice or complex things, and there *are* macros like that
in real code) you better make it of type Foo*.

Yevgen

What are you NOT getting about the fact that the cast is not needed in ISO C?
Do you know the purpose and characteristics of void pointers?

malloc() takes a size_t, that is IT. It does not talk to, worth with, or have
beers with sizeof to figure out what the type is.

[Christopher Layne]

Yevgen Muntyan wrote:

It seems I forgot that you're talking here about strictly conforming
code here. Indeed, if you have a strictly conforming program then
[...]
foo.h:

#define FOO_NEW() ...

simply can't be in a strictly conforming program and you use
only malloc(whatever ) (or calloc, etc.) in your code. Yes, using only
standard features promotes use of raw malloc, and yes, casting
raw malloc in regular code like

At this point I can't tell if you're trolling or just don't know what you're
talking about Yevgen.

[Yevgen Muntyan]

Richard Bos wrote:

Ryan Ply <th******@earth ling.netwrote:

>rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

>>I don't use Emac-OS, and even if I did, abrv. mode would not solve the
more important problem of making the malloc()-caster less attentive. As
for "solving" the warnings, that's like "solving" a stinging pain in
your right side by taking morphine. Yes, it _does_ get rid of the pain,
but you'll still die of a burst appendix sooner or later. It's better
get rid of the cause of the pain (read: warning messages) than to ignore
it.

People just like reading whatever they want instead of whats on the
screen in front of them. Someone said that by casting it would hide or
mask the compilers warnings to me. I put extra flags in so that these
warnings return as if nothing happened. Thus "solved".

Wrong.

> I program for real targets, not would be possible maybe in some day
embedded targets 20 years form now possibly.

The meaning of that sentence is as muddled as its grammar.

>That is how specific compiler options are safe to use for me.

Wrong.

> When I get a project with a vague target then
things will be different, but that hasn't happened to date.

But don't mind me; just don't come whining when your habit of ignoring
valid warnings comes back to bite you in the arse.

Since the discussing went too far from here, let me repeat the MAIN
point. I was replying to this thing, that Richard Bos said Ryan Ply
ignored valid warnings while Ryan Ply actually made his compiler
to warn about real problem. The real (potential) problem is missing
header which leads to UB, not converting int to pointer which is a bogus
side effect.

And what I am saying is: you got to read very very carefully
what you are replying to if you are going to use these stupid
"Wrong period Don't come whining when...".

Yevgen

[Yevgen Muntyan]

Christopher Layne wrote:

Yevgen Muntyan wrote:

>>>#define FOO_NEW() ((Foo*) malloc (sizeof (Foo))) // *must* cast here
No. It's not. It's not clear, it's obtuse and pointless monkeying that
*reduces* visible intent.

What do you do if you need to replace malloc() with another allocator?
Grep? While this macro is indeed stupid, it was an example of where
cast is needed.
*If* you write a macro which allocates a Foo structure (this macro can
do arbitrary nice or complex things, and there *are* macros like that
in real code) you better make it of type Foo*.

Yevgen

What are you NOT getting about the fact that the cast is not needed in ISO C?
Do you know the purpose and characteristics of void pointers?

You're not kidding, are you? I said *I need* cast because I want a safer
expression. If I apply cast, the expression acquires a type.

((Type*) malloc (sizeof (Type)))

is a standalone expression of type Type* (and it's an allocated chunk
of memory). Of course I can avoid cast here, but I believe void* is
worse than Type* when I need Type*.

I do get the fact that cast is not needed in ISO C.

malloc() takes a size_t, that is IT. It does not talk to, worth with, or have
beers with sizeof to figure out what the type is.

Yep, and this is why I apply cast to make an expression which has beer
with its argument every Friday.

Yevgen