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]

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

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

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.

If it's foisted on you, it's not a very good example in a discussion
about what is and is not good design, though, is it?

I'm using

int WINAPI WinMain(HINSTAN CE instance, HINSTANCE previnst__,
PSTR cmdline, int showmode)

because I have to. That doesn't mean I think it's good design to include
a function parameter you never use and haven't for years, or even that
the above is valid C.

Richard

[Flash Gordon]

Yevgen Muntyan wrote, On 09/02/07 00:34:

Flash Gordon wrote:

>Yevgen Muntyan wrote, On 08/02/07 19:14:

>>Flash Gordon wrote:
Yevgen Muntyan wrote, On 08/02/07 13:34:
Christoph er Layne wrote:
>Yevgen Muntyan wrote:

<snip>

>>>However, the *habit* of casting is always a bad habit and the habit
of casting malloc is always a bad habit.

Yes, such a *habit* is bad. Did I tell it's not?

You seem to be saying there is nothing wrong with doing something even
though if it becomes a habit it is a bad habit. Habits are formed by
repeatedly doing things, so if you want to avoid having bad habits do
not engage in the practices which are bad habits.

I do not engage in those practices to my best knowledge. At least
not with casting return value of malloc. I don't cast it normally.
I do cast it when I need to (usually it's C++ or allocation
macros in headers). And I am not saying it's okay to cast stuff
here and there. I am saying that some folks in this newsgroup
must apply some consideration and thinking before spitting
stupid "Wrong."

You have yet to come up with a convincing reason for doing it, so there
is so far no convincing reason for people not to say it is the wrong
thing to do.

>>>I have seen exactly one person come up with a convincing reason why
he should cast the value returned by malloc in his specific
situation. That reason is at least in part due to commercial reality
rather than technical merit.

Note the compatibility with C++ is a bad reason because:
1) In C++ there are better methods than using malloc to get memory

You lose compatibility with C then ;)

Actually, than is not necessarily true. There are ways of creating
interfaces for C code to call C++ code.

Tenth time: *compiling* C code with C++ compiler. It is necessarily
true that C compiler won't accept "new Foo" (we don't talk crazy
"C/C++" compilers and funny macros, right?).

In that case, for the 11th time there is no reason to compile C code
with a C++ compiler. If you want to access C code from C++ then use the
methods defined in C++ otherwise don;t, but either way compile your C
code as C and your C++ code as C++.

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

Simple solution, don't do it. Apart from anything else there are
subtle differences between C and C++ such that a program can be valid
as both but behave differently.

And there is lot of C code which behaves in the same way. E.g.

foo.h:
---------------------------
#ifdef __cplusplus
extern "C" {
#endif

typedef struct Foo Foo;

void *alloc_some_mem (size_t n);

#define ALLOC_FOO() ((Foo*) alloc_some_mem (sizeof (Foo)))

#ifdef __cplusplus
}
#endif
---------------------------

Yes, it is the same. Whether presented to someone who know C or C++ they
will tell you it is the wrong thing to do. Given the above delete the
#define and just call alloc_some_mem when you want to use it, calling
from C code without the cast calling from C++ code with the cast
(although using it from C++ code would probably be a bad thing). So by
deleting one line the problem goes away.

I won't try to talk about other cases when one really wants to compile
his C code with C++ compiler, since there is an easy solution, "don't do
it". I really love these simple solutions: the problem is to do this
and this; the solution is not to do this and this and do that instead.
Works like a charm in an argument.

It is also the best solution. The languages *are* different. You don't
try to compile you C code with a Java compiler or run it in a Perl
interpreter, so why try to compile it with a C++ compiler?
--
Flash Gordon

[Flash Gordon]

Yevgen Muntyan wrote, On 09/02/07 04:47:

Keith Thompson wrote:

>Yevgen Muntyan <mu************ ****@tamu.eduwr ites:

>>Mark McIntyre wrote:

[...]

>>>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". 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 :)

No, C code doesn't become C++ code because you feed it to g++. If g++
accepts it (assuming g++ to be a correctly working C++ compiler), then
it was *already* C++ code.

What you're talking about is code that is simultaneously C code and
C++ code.

Yes.

Now tell us why you want code that is both. A good technical reason not,
"well it means I can feed it to a C or a C++ compiler" since that is a
circular argument.

>I don't want to get too deeply into this argument, but I will say
that, in my opinion, there is rarely a real need to write such code.
(I said "rarely", not "never".)

And this is the key point: "rarely" is not "never".
Though it's not really that rare, just look at /usr/include/*.h or
whatever_path\i nclude\*.h. Lots of C code which is
intentionally made C++-compatible. Lately only die-hard
hate-c-plus-plus folks make public C headers not C++-compatible
if they want their libraries to be used

How many times can you find casts of the return value of malloc in the
*headers*. Those headers are for defining interfaces and so should not
in general include code. After all, how would you use those libraries
from Ada, Fortran etc if it relies on code in C header files?

I indeed was
talking not about this (except the parts about headers
of course). I did talk about doing "g++ foo.c". Anyway,
nobody is really talking about technical stuff. Technical
stuff is used in this discussion to justify blind stupid
"Wrong period". Whatever.

You have yet to provide a good reason for feeding your C code to a C++
compiler so you have yet to back up your argument that it is not the
wrong thing to do.
--
Flash Gordon

[matevzb]

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

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

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

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.

If it's foisted on you, it's not a very good example in a discussion
about what is and is not good design, though, is it?

I'm using

int WINAPI WinMain(HINSTAN CE instance, HINSTANCE previnst__,
PSTR cmdline, int showmode)

because I have to. That doesn't mean I think it's good design to include
a function parameter you never use and haven't for years, or even that
the above is valid C.

Note that I didn't say that using sizeof *ptr is bad and that
sizeof(<type>) is good design. I was pointing out that in my opinion
sizeof(<type>) doesn't promote bad habits per se. To me, it's a
stylistic issue, and I haven't (yet) been convinced otherwise =) For
others of course, it may be more than that...
--
WYCIWYG - what you C is what you get

[Christopher Layne]

Yevgen Muntyan wrote:

Perhaps I should have said that I don't think casting return value of
malloc is a good idea? Instead of not-saying which gets interpreted
as saying-the-contrary.

Yevgen

Dude, cast malloc until the day you die then. Freedom for all malloc()
casters, la la la. It's not big enough to argue for a week, so I'm done with
this discussion.

[Christopher Layne]

Richard Bos wrote:

I'm using

int WINAPI WinMain(HINSTAN CE instance, HINSTANCE previnst__,
PSTR cmdline, int showmode)

because I have to. That doesn't mean I think it's good design to include
a function parameter you never use and haven't for years, or even that
the above is valid C.

Richard

Ugh. Win32.

You've got to love API calls that take 13 parameters - 7 of which can randomly
be set to 0 or NULL (just decide at the flip of a coin) and no effect will be
noticed.

[Christopher Layne]

matevzb wrote:

Note that I didn't say that using sizeof *ptr is bad and that
sizeof(<type>) is good design. I was pointing out that in my opinion
sizeof(<type>) doesn't promote bad habits per se. To me, it's a
stylistic issue, and I haven't (yet) been convinced otherwise =) For
others of course, it may be more than that...
--
WYCIWYG - what you C is what you get

I guess you think it looks cleaner or more advanced or something of that
nature. When in the long run it's just more freakin' work with zero gain.

[Christopher Layne]

Yevgen Muntyan wrote:

You snipped the piece where I said when I need to. Sure, you
can say that I can just avoid using malloc and alike in headers.
The same "simple solution" as was offered elsewhere: avoid
situations where you need cast and you will not need cast.
But I still believe that

#define ALLOC_A_THING(T ype) ((Type*) malloc (sizeof (Type)))

is not too bad.

Yevgen

I think you have a penchant for being needlessly contrary.

[Christopher Layne]

Yevgen Muntyan wrote:

Even with malloc this macro is more convenient than malloc(sizeof *foo)
or malloc(sizeof(F oo)) (given the name is better than
"custom_allocat or_here"). Some people even believe it's safer than
raw malloc. Or

#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.

[Yevgen Muntyan]

Christopher Layne wrote:

Yevgen Muntyan wrote:

>Even with malloc this macro is more convenient than malloc(sizeof *foo)
or malloc(sizeof(F oo)) (given the name is better than
"custom_alloca tor_here"). Some people even believe it's safer than
raw malloc. Or

#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