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 Bos]

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

Lots of stuff that could, possibly, maybe happen. As for the "possibly
harmful for malloc" comment, its if malloc fails to be declared as
returning void *. Is there an place where it isn't? I suppose my point
is that I don't understand why I should program for things that have a
firm chance of a definite maybe of happening.

Good point. So why cast at all? It solves nothing that deserves solving,
it involves more keypresses, and it does degrade the warning value of
real casts. The last one is the killer, IMO: casting malloc() is like
hanging a High Voltage sign on every home outlet. It means that when you
_need_ the warning, you've been trained to think "Oh, just another
meaningless High Voltage sign/pointer cast, let's ignore it", and get
zapped to a crisp/get your program segfaulted. Don't train yourself not
to pay attention; don't cast malloc().

Richard

[Richard Bos]

ri*****@cogsci. ed.ac.uk (Richard Tobin) wrote:

In article <bd************ @news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwro te:

>Then that must have been a non-C89 compliant version and the "few
years" is probably more than a decade (or you actually had forgotten
to include <stdlib.h>;-)

Or perhaps the system's stdlib.h didn't declare malloc()? Given the
existence of malloc.h on some systems, that wouldn't be too
surprising.

The the system's stdlib.h does not declare malloc then it is not C89
compliant and hence is covered by that Jens stated.

I read Jens' statement as implying that the version of *gcc* must more
than a decade old. But gcc generally uses the system headers and
libraries, so it might have been the system rather than gcc that was
out-of-date.

Possibly, but that's a poor cop-out, IMO. You work with an
implementation, not with two half-implementations . Ganoo (i.c.) passing
the buck to Aitch Pee (e.g.), and Aitch Pee passing the buck back to
Ganoo, makes both of them guilty for together delivering a broken
implementation, not neither of them. Neither the Standard nor the end
user cares, nor should they care, that parts of the implementation came
from different suppliers.

Richard

[Richard Tobin]

In article <45************ *****@news.xs4a ll.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwr ote:

>I read Jens' statement as implying that the version of *gcc* must more
than a decade old. But gcc generally uses the system headers and
libraries, so it might have been the system rather than gcc that was
out-of-date.

>Possibly, but that's a poor cop-out, IMO.

It might be a cop-out if someone from the gcc team said it, but I have
nothing to do with them, so it's just a possible explanation (perhaps
an unlikely one, as some have said).

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

[Ryan Ply]

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

Good point. So why cast at all? It solves nothing that deserves solving,
it involves more keypresses, and it does degrade the warning value of
real casts.

Abbrev mode is your friend, assuming you use emacs that is. Some quick
reading of man pages as to proper compiler flags will solve the
warnings.
Also to Richard Heathfield:

Technique 1 (your way) requires you to include the <stdlib.hhead er
and requires you to type a pointer cast and requires you to fix the
cast if the type changes.

Technique 2 (which is what we like to call "the right way") requires
you to include the header.

So we're suggesting that you might like to do less work and get a
better, more maintainable program as a result. But hey, no pressure -
if you want to keep doing it in some way other than the right way,
that's up to you - I mean, some people just love to type, right?

stdlib.h is has been in my .c template for as long as I can remember,
I'm not sure why this newsgroup assumes it isn't. All I've said that
would allude to it not being there was in reference to an old gcc
compiler, probably 2.95 or earlier.

Its also not more keystrokes for me, I have abbrev lists, it also make
my code cleaner as I can compare the number of 'stars' * in the cast
versus the number inside the malloc and have virtually eliminated my
pointer problems by doing that. I'm suggesting that I'm doing less work
and getting a more maintainable program as a result. That's just me.

Ryan -

[Ben Bacarisse]

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

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

>Good point. So why cast at all? It solves nothing that deserves solving,
it involves more keypresses, and it does degrade the warning value of
real casts.

Abbrev mode is your friend, assuming you use emacs that is.

You have set up a tool to help you add unnecessary casts?

Some quick
reading of man pages as to proper compiler flags will solve the
warnings.

I think you miss Richard Bos's point. I think he means that one huge
advantage of casts is they alert one to problems. If you need one,
then things have got sticky. If you use them where they are not
needed they can't be used as a strong flag, drawing the reader's
attention to important problems.

Also to Richard Heathfield:

>Technique 1 (your way) requires you to include the <stdlib.hhead er
and requires you to type a pointer cast and requires you to fix the
cast if the type changes.

>Technique 2 (which is what we like to call "the right way") requires
you to include the header.

>So we're suggesting that you might like to do less work and get a
better, more maintainable program as a result. But hey, no pressure -
if you want to keep doing it in some way other than the right way,
that's up to you - I mean, some people just love to type, right?

stdlib.h is has been in my .c template for as long as I can remember,
I'm not sure why this newsgroup assumes it isn't. All I've said that
would allude to it not being there was in reference to an old gcc
compiler, probably 2.95 or earlier.

Its also not more keystrokes for me, I have abbrev lists, it also make
my code cleaner as I can compare the number of 'stars' * in the cast
versus the number inside the malloc and have virtually eliminated my
pointer problems by doing that.

What problems? If you use the recommended idiom:

p = malloc(<exp* sizeof *p);

you know the type will be correct, and no casts!

I'm suggesting that I'm doing less work
and getting a more maintainable program as a result. That's just
me.

Yes, just you!

--
Ben.

[Mark McIntyre]

On 02 Feb 2007 08:33:03 -0800, in comp.lang.c , Ryan Ply
<th******@earth ling.netwrote:

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

>Good point. So why cast at all? It solves nothing that deserves solving,
it involves more keypresses, and it does degrade the warning value of
real casts.

Abbrev mode is your friend, assuming you use emacs that is.

You've programmed your environment to automatically do something
unnecessary and potentially harmful. Ask yourself why you'd want to do
that.

>Some quick
reading of man pages as to proper compiler flags will solve the
warnings.

You miss the point - with the cast in place, warnings are
/suppressed/, even when they would have been valid. With the cast
removed, the only warnings you should get are if you actually did make
a mistake.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Ian Collins]

Ryan Ply wrote:

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

>>Good point. So why cast at all? It solves nothing that deserves solving,
it involves more keypresses, and it does degrade the warning value of
real casts.

Abbrev mode is your friend, assuming you use emacs that is. Some quick
reading of man pages as to proper compiler flags will solve the
warnings.

Solve the warnings? Warnings are your friend, fix them, don't sweep
them under the the rug.

--
Ian Collins.

[Christopher Layne]

Ryan Ply wrote:

Its also not more keystrokes for me, I have abbrev lists, it also make
my code cleaner as I can compare the number of 'stars' * in the cast
versus the number inside the malloc and have virtually eliminated my
pointer problems by doing that. I'm suggesting that I'm doing less work
and getting a more maintainable program as a result. That's just me.

Ryan -

But you're being irrational and refusing to change your ways after being shown
that it is a pointless and sometimes dangerous way.

Go read up on pointers of type void.

[CBFalconer]

Ben Bacarisse wrote:

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

>>

.... snip ...

>>
stdlib.h is has been in my .c template for as long as I can
remember, I'm not sure why this newsgroup assumes it isn't.
All I've said that would allude to it not being there was in
reference to an old gcc compiler, probably 2.95 or earlier.

Piggybacking here.

Why should you always include stdio.h? In many cases it is
unnecessary, and even not available (in some embedded systems). An
example is my implementation of strlcpy/cat, which is usable
unchanged on such systems. Just put in the things you need. The
other attitude leads to such abortions as windows.h.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Richard Heathfield]

CBFalconer said:

Ben Bacarisse wrote:

>Ryan Ply <th******@earth ling.netwrites:

>>>

... snip ...

>>>
stdlib.h is has been in my .c template for as long as I can
remember, I'm not sure why this newsgroup assumes it isn't.
All I've said that would allude to it not being there was in
reference to an old gcc compiler, probably 2.95 or earlier.

Piggybacking here.

Why should you always include stdio.h?

Why indeed? But he didn't claim you should, or that he does, always include
<stdio.h- he was actually referring to <stdlib.h>, and he doesn't even
claim always to include /that/ - he merely said it was in his ".c
template". Presumably that's some kind of stamp with which he churns out C
source file skeleta - and presumably he can remove <stdlib.hfrom a given
source if it turns out not to be required therein.

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