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

[Richard Bos]

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.

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.

Richard

 

[Ryan Ply]

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". I program for
real targets, not would be possible maybe in some day embedded targets
20 years form now possibly. That is how specific compiler options are
safe to use for me. When I get a project with a vague target then
things will be different, but that hasn't happened to date.


Ryan -

 

[Richard Heathfield]

Ryan Ply said:

(e-mail address removed) (Richard Bos) writes:



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.

Yes, it may well hide or mask the warning, in the same way (as Richard B
graphically points out) that morphine hides or masks the pain of a
burst appendix. But just as morphine doesn't cure a burst appendix,
neither does casting malloc cure the problem that causes the compiler
to generate a warning.

I put extra flags in so that these
warnings return as if nothing happened. Thus "solved". I program for
real targets, not would be possible maybe in some day embedded targets
20 years form now possibly.

In this newsgroup, we have had people post code which exhibits serious
behavioral problems, and these problems vanished like the dawn mist
when they followed our advice to remove the cast and add the
appropriate header instead. This is not an academic issue.

 

[santosh]

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". I program for
real targets, not would be possible maybe in some day embedded targets
20 years form now possibly. That is how specific compiler options are
safe to use for me. When I get a project with a vague target then
things will be different, but that hasn't happened to date.

Eliminating non-essential casts is not mutually exclusive with
programming for "real targets" or whatever else you mean.

 

[Richard Bos]

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.

Richard

 

[Yevgen Muntyan]

Wrong.

What's wrong? Ryan Ply said couple of times that he gets his warnings,
and indeed, for instance gcc warns about undeclared malloc() with or
without cast. Cast *may* (perhaps) suppress the warning, but it doesn't
for Ryan, so he's good. Are there other other reasons not to cast
(except the obvious one, why cast if it works fine without cast)?

Yevgen

 

[Richard Bos]

What's wrong?

Stomped over != solved.

Are there other other reasons not to cast

RTFThread. It's right up there ^^^.

Richard

 

[Yevgen Muntyan]

Stomped over != solved.

Stomped over *what*? I believe you are saying he suppresses
warnings using cast. It's not the case. Are you talking about something
else?

RTFThread. It's right up there ^^^.

Sorry, I've seen only one bad thing - suppressing warnings. I might
have missed something, of course. I've seen "cast hides the problems",
but what problems? If compiler warns you about missing prototype, you
add missing #include, and then you're totally good - prototype is in
place, casting void* to whatever* is fine; if whatever* is not the
right type you get another warning (or compilation error). What exactly
are those problems?

Yevgen

 

[Mark McIntyre]

Stomped over *what*? I believe you are saying he suppresses
warnings using cast. It's not the case.

No, he's saying that its not a good idea to hide warnings.

Sorry, I've seen only one bad thing - suppressing warnings. I might
have missed something, of course. I've seen "cast hides the problems",
but what problems?

This is practically a FAQ - oh look, it is. In fact its a whole bunch
of them...
--
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

 

[santosh]

Sorry, I've seen only one bad thing - suppressing warnings. I might
have missed something, of course. I've seen "cast hides the problems",
but what problems? If compiler warns you about missing prototype, you
add missing #include, and then you're totally good - prototype is in
place, casting void* to whatever* is fine; if whatever* is not the
right type you get another warning (or compilation error). What exactly
are those problems?

Without a prototype, *alloc() are assumed to return an int. They, of
course, return a void pointer value. Assigning an int value, which is
itself derived from a void pointer value, to a pointer to T should
produce a diagnostic, if not for the unneccessary cast. So the casting
hides the fact that no prototype is in scope, and it forces a type
conversion which is not guaranteed to produce meaningful results on
all implementations.

 

[Yevgen Muntyan]

Without a prototype, *alloc() are assumed to return an int. They, of
course, return a void pointer value. Assigning an int value, which is
itself derived from a void pointer value, to a pointer to T should
produce a diagnostic, if not for the unneccessary cast. So the casting
hides the fact that no prototype is in scope, and it forces a type
conversion which is not guaranteed to produce meaningful results on
all implementations.

Okay, let me repeat: casting does *not* hide the warning about missing
prototype here. It does suppress the warning about converting int to
pointer, but there is a warning about missing prototype. It *is* there.
So, if you do

int main (void)
{
char *ptr = (char*) malloc(10);
return 0;
}

then you don't get warning about converting int to pointer, but it's not
a problem. Because: you get real warning about real problem, namely
about missing prototype. Warning about converting int to a pointer is
just a side effect when you miss needed #include. You get a warning
about *real* problem, you fix the *real* problem, and then you don't
care about bogus warning about some casts.

I said about it twice, and Ryan Ply said about it at least twice. Try
yourself 'gcc -W -Wall' if you don't believe it.

Yevgen

 

[Walter Roberson]

Okay, let me repeat: casting does *not* hide the warning about missing
prototype here. It does suppress the warning about converting int to
pointer, but there is a warning about missing prototype. It *is* there.

I said about it twice, and Ryan Ply said about it at least twice. Try
yourself 'gcc -W -Wall' if you don't believe it.

I don't use gcc, and you are presuming an awful lot about the properties
of the compilers that I do use.

There is no requirement that an implementation produce a diagnostic
for a missing prototype.

 

[santosh]

Okay, let me repeat: casting does *not* hide the warning about missing
prototype here. It does suppress the warning about converting int to
pointer, but there is a warning about missing prototype. It *is* there.

Is such a diagnostic required by the standard? If not, then casting
*does* complicate the discovery of the potential bug by silencing the
compiler with regards to another dangerous construct.

Besides since a void pointer is convertable to a pointer to any type,
why is the cast neccessary in the first place?

 

[Charlton Wilbur]

s> Besides since a void pointer is convertable to a pointer to any
s> type, why is the cast neccessary in the first place?

Because C++ decided to make the implicit cast from void * to another
pointer type a semantic error.

When you see a programmer painstakingly casting the return value from
malloc(), you can be sure he imprinted on C++ or was taught by people
who did. Old habits die hard.

Charlton

 

[Ben Pfaff]

When you see a programmer painstakingly casting the return value from
malloc(), you can be sure he imprinted on C++ or was taught by people
who did. Old habits die hard.

Or that he started out with pre-ANSI C, some versions of which
also required the cast.

 

[Yevgen Muntyan]

I don't use gcc, and you are presuming an awful lot about the properties
of the compilers that I do use.

So you don't use gcc and your compiler doesn't have a warning about
missing declarations (I doubt it), fine. You don't want the cast.
Did I tell *you* should cast?

Thing is that bunch of people jumped onto Ryan Ply saying he
does a bad thing and everything, though it wasn't the case. Those
people (including you apparently, because I didnt' say anything
about your compiler and you're saying I am presuming something
about it) did not read what Ryan actually said. And then they
magically translated "I do it this way" into "You all shall do
it this way".

I am not saying "you should cast". I am saying "Ryan Ply is fine
because he knows what he is doing and he is doing a right thing". The
"don't cast result of malloc" is a good rule of thumb in general. But
there are situations (like this one) when cast is harmless, and might
be actually needed. Maybe one wants to compile it with C++ compiler,
or he likes the cast, the cast is valid and correct. And, it
does *not* suppress the warning about the *real* problem, the
problem of not including needed header.

There is no requirement that an implementation produce a diagnostic
for a missing prototype.

I didn't say there is such a requirement. Did I or someone else say it?
The problem is that Ryan said one thing ("works fine for me because
I make it so explicitely") and you all treated him like an fool which
doesn't read the FAQ or something.

Yevgen

 

[CBFalconer]

.... snip ...

Okay, let me repeat: casting does *not* hide the warning about
missing prototype here. It does suppress the warning about
converting int to pointer, but there is a warning about missing
prototype. It *is* there. So, if you do

int main (void)
{
char *ptr = (char*) malloc(10);
return 0;
}

then you don't get warning about converting int to pointer, but
it's not a problem. Because: you get real warning about real
problem, namely about missing prototype. Warning about converting
int to a pointer is just a side effect when you miss needed
#include. You get a warning about *real* problem, you fix the
*real* problem, and then you don't care about bogus warning about
some casts.

After deleting the useless and potentially harmful cast, we get:

junk.c: In function `main':
junk.c:3: warning: implicit declaration of function `malloc'
junk.c:3: warning: initialization makes pointer from integer
without a cast
junk.c:3: warning: unused variable `ptr'

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

 

[Mark McIntyre]

Okay, let me repeat: casting does *not* hide the warning about missing
prototype here.
agreed.

It does suppress the warning about converting int to
pointer,

which arises because of hte missing prototype.

but there is a warning about missing prototype. It *is* there.

In C89 there's no requirement for a prototype to be in scope. A
compiler can complain about it, but its a QoI issue not an actual
error.

I said about it twice, and Ryan Ply said about it at least twice. Try
yourself 'gcc -W -Wall' if you don't believe it.

You may have said it twice, but that just makes it twice as
inaccurate!
--
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

 

[Yevgen Muntyan]

which arises because of hte missing prototype.


In C89 there's no requirement for a prototype to be in scope. A
compiler can complain about it, but its a QoI issue not an actual
error.


You may have said it twice, but that just makes it twice as
inaccurate!

Okay, it's really funny how people read not what's written.
I am *not* saying any compiler must emit warning about missing
prototype. I am saying gcc does it when you use -W -Wall.
And Ryan Ply said he uses appropriate compiler flags to get
the warning.

Me: I am fine here, I make gcc take care of this.
You: No, you're wrong. anycc is not obliged to emit a warning.
Me: *I* make *gcc* take care of this *here*.
You: No, you're wrong. See above.

Yevgen

 

[Yevgen Muntyan]

Yevgen Muntyan wrote:
... snip ...

After deleting the useless and potentially harmful cast, we get:

junk.c: In function `main':
junk.c:3: warning: implicit declaration of function `malloc'
junk.c:3: warning: initialization makes pointer from integer
without a cast
junk.c:3: warning: unused variable `ptr'

Yep, "implicit declaration of function `malloc'". The warning
about actual problem - missing include. You fix the problem and
you're good.

Yevgen