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

[Mark McIntyre]

On Thu, 08 Feb 2007 13:14:44 -0600, in comp.lang.c , Yevgen Muntyan

Flash wrote

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.

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

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.

Unless you are using C++ constructs to test your C...

 

[Chris Torek]

I am not *mandating* anything! I am saying that *if* I use -W -Wall,
then casting return value of malloc() doesn't cause any troubles.
Do you not agree with this one exact sentence?

I agree with that sentence. I also agree, however, that it is
possible to mow one's lawn with a flamethrower. I would not
recommend that either.

 

[CBFalconer]

.... snip ...

What promotes bad habits? Bad habits? Okay, let it be a bad habit
to cast return value of malloc (which I agree with if it's "always
cast"). Do you say that it's fine to claim that the cast in the
following code

#include <stdlib.h>
int main (void)
{
char *foo = (char*) malloc (18);
return 0;
}

*necessarily* and *always* leads to bad results for every single
person in every single situation? Please don't say about habits,
just say "yes" or "no" (and read the thread to see what I am
talking about if you're interested).

Always. He has typed at least eight unnecessary characters,
leading to broken fingernails, various muscular problems, not to
mention the extraneous discussion here and added probability of
spilling coffee (or other liquids) into the keyboard. The program
is also fatally flawed by failure to #include <stdlib.h>, while the
inclusion of stdio.h is totally unnecessary (another 19 excess
chars typed).

--
Some free news servers. I use teranews and gmane.
<http://www.teranews.com> (1 time charge) (free)
<http://news.aioe.org> (free)
<http://dotsrc.org> (free)
<http://www.x-privat.org/international.php> (free)
<http://motzarella.org/?language=en> (free)
<http://gmane.org/> (mail-lists via news) (free)
<http://www.newsfeeds.com/signup.htm> (pay)
<http://www.individual.net/ (low pay)

 

[CBFalconer]

Flash Gordon wrote:
.... snip ...


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

This is an extremely silly thing to do. The languages are
different. A C compiler compiles C source, while a C++ compiler
compiles C++ source. There is one regular user of this newsgroup
who follows that practice, because he deals with idiots who do not
know the difference, and the ability avoids support problems
explaining their idiocy in dulcet and inoffensive tones, thus
improving his standard of living.

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

"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

 

[Yevgen Muntyan]

On Thu, 08 Feb 2007 13:14:44 -0600, in comp.lang.c , Yevgen Muntyan

Flash wrote


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.

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

Regards,
Yevgen

 

[CBFalconer]

.... snip ...

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.

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

"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

 

[Yevgen Muntyan]

I assume you got the point, and are merely trying to avoid it.


Sure, if during that 2 months, you upgraded your compiler, OS or
target infrastructure.

You mean you upgrade compiler or OS and it breaks valid correct
code? It will break valid code without cast as well. I am sure
it's not what you meant. You were talking about habits here,
like if I'm used to gcc producing warning and rely on that,
it will beat me. This is certainly true, and I don't cast return
value of malloc if I don't need to. Still, existing cast
in valid correct code is *not* a problem.

But when some person says "it's not a problem", he gets a laconic
response "Wrong.", the response from a person who didn't try hard
to understand what he was replying to. And that's the problem.
You get flamed for using potentially harmful construct *without*
any questions. You use it, you're moron. Full stop.

And malloc is a case where you don't have to.

Not always. But yes, usually casting return value of malloc
is not a good idea.

Nobody ever said that.

Oh yeah people in this thread did say that. That's what the
fuss is about.

Yevgen

 

[Yevgen Muntyan]

Yevgen Muntyan wrote:
... snip ...

Always. He has typed at least eight unnecessary characters,
leading to broken fingernails, various muscular problems, not to
mention the extraneous discussion here and added probability of
spilling coffee (or other liquids) into the keyboard. The program
is also fatally flawed by failure to #include <stdlib.h>, while the
inclusion of stdio.h is totally unnecessary (another 19 excess
chars typed).

Which program is fatally flawed? The one that broke your fingernails?
Or the posted one? Or some other? And who's "he"?

Yevgen

 

[Yevgen Muntyan]

matevzb wrote:
... snip ...

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

You didn't read what you were replying to, did you?

Yevgen

 

[Flash Gordon]

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

If you use editor's search to modify code then you'll get errors,
just because this edit is that complex. And you'll get errors
unrelated to malloc()

So take the simpler option for editing of using
ptr = malloc(N * sizeof *ptr);

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.

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.

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.

 

[Ian Collins]

.... snip ...


This is an extremely silly thing to do. The languages are
different. A C compiler compiles C source, while a C++ compiler
compiles C++ source. There is one regular user of this newsgroup
who follows that practice, because he deals with idiots who do not
know the difference, and the ability avoids support problems
explaining their idiocy in dulcet and inoffensive tones, thus
improving his standard of living.

You wouldn't be referring to me would you?

If so, what have I done to you to deserve such an ignorant insult?

How can you argue against using C++ objects to simulate hardware in
order to test C device drivers?

 

[Keith Thompson]

You wouldn't be referring to me would you?

[snip]

I'm sure he was referring to P.J. Plauger (though I'm not aware of any
basis for referring to his customers as idiots).

 

[Yevgen Muntyan]

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

So take the simpler option for editing of using
ptr = malloc(N * sizeof *ptr);



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

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

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

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.

Yevgen

 

[Richard Heathfield]

CBFalconer said:

Always. He has typed at least eight unnecessary characters,
leading to broken fingernails, various muscular problems, not to
mention the extraneous discussion here and added probability of
spilling coffee (or other liquids) into the keyboard.

All most droll, Chuck, but...

The program
is also fatally flawed by failure to #include <stdlib.h>
....wrong...

, while the
inclusion of stdio.h is totally unnecessary (another 19 excess
chars typed).

....and wrong again.

 

[Richard Heathfield]

Yevgen Muntyan said:

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

In which case you never cast it, since it's never necessary.

 

[CBFalconer]

You wouldn't be referring to me would you?

[snip]

I'm sure he was referring to P.J. Plauger (though I'm not aware of
any basis for referring to his customers as idiots).

I'm sure some are, otherwise he would not need to proof his
shrouded software against miscompiling.

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

"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

 

[Yevgen Muntyan]

Yevgen Muntyan said:



In which case you never cast it, since it's never necessary.

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(Type) ((Type*) malloc (sizeof (Type)))

is not too bad.

Yevgen

 

[CBFalconer]

CBFalconer said:

All most droll, Chuck, but...


...and wrong again.

Damn. I could have sworn I read stdio there. There goes my
perfect record. The nits are getting out of hand.

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

"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

 

[matevzb]

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.