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

[robertwessel2]

CBF> Are there any reliable estimates as to the number of wood
CBF> stove fires annually kindled by BullSchildt books? I have
CBF> the impression the value has been dropping for several years.
CBF> This may be correlated with the disappearance of Herbs from
CBF> the C book market.

Alas, I was in a bookstore earlier this week, and pride of place in
the C section, meager as it was, was given to _C: the Annotated
Reference_. At least K&R was also there.

Well, at least it's a cheap way of picking up a copy of the c89
standard. Well, except for that missing page...

 

[Ben Pfaff]

Well, at least it's a cheap way of picking up a copy of the c89
standard. Well, except for that missing page...

_C: The Annotated Reference_ != _The Annotated ANSI C Standard_

 

[robertwessel2]

_C: The Annotated Reference_ != _The Annotated ANSI C Standard_

Mea culpa.

 

[Keith Thompson]

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.[/QUOTE]

Actually, it would be very surprising. Quoting the Rationale:

The header <stdlib.h> was invented by the C89 Committee to hold an
assortment of functions that were otherwise homeless.

There's never been a specification for <stdlib.h> that didn't include
a declaration of malloc().

It's far more likely that somebody forgot the "#include <stdlib.h>",
causing the compiler to assume that malloc() returns int.

 

[Keith Thompson]

CBF> Are there any reliable estimates as to the number of wood
CBF> stove fires annually kindled by BullSchildt books? I have
CBF> the impression the value has been dropping for several years.
CBF> This may be correlated with the disappearance of Herbs from
CBF> the C book market.

Alas, I was in a bookstore earlier this week, and pride of place in
the C section, meager as it was, was given to _C: the Annotated
Reference_. At least K&R was also there.

[...]

Are you sure about that title? Schildt has a book called _C: The
Complete Reference_, and another (now out of print) called _The
Annotated ANSI C Standard_. The latter was a useful way to get a copy
of the C90 standard, but the annotations were positively dangerous.

 

[Keith Thompson]

That must have been a C++ compiler. No actual ISO compliant C compiler
has ever been allowed to complain about it. Or else you forgot to
incude stdlib.h of course.

Strictly speaking, a compiler is allowed to complain about anything it
likes. But yes, if it complains about a malloc() call with no cast,
it's probably because <stdlib.h> wasn't included or because it's a C++
compiler.

 

[Ryan Ply]

You were using a C++ compiler.

From the gcc man page:
"For any given input file, the file name suffix determines what kind of
compilation is done"

My file extensions are *.c (lowercase), therefore a C compiler.

Read the errata for K&R.

I see in the errata these fun phrases. "the advice is debatable",
"possibly harmful", "can cover up an unintended error".

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.

Ryan -

 

[Charlton Wilbur]

KT> [...]

KT> Are you sure about that title?

Honestly, no. I have K&R and Harbison & Steele on my shelf; I
registered a big thick book by Schildt, and as I wasn't even looking
for a C reference, I didn't look much closer.

Charlton

 

[Christopher Layne]

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.

Ryan -

Okay, why bother casting? Does it make you feel better? The language rules are
in full effect if you are not explicitly casting the return value from any of
the allocation functions (or any void * returning function for that matter).
Do you not trust this?

By casting the return value, you're reinstilling a misunderstanding of
the "rules" if you will.

Are you afraid of void *? It's your friend you know.

 

[Richard Heathfield]

Ryan Ply said:

I see in the errata these fun phrases. "the advice is debatable",
"possibly harmful", "can cover up an unintended error".

Lots of stuff that could, possibly, maybe happen.

And, in fact, has happened on quite a few occasions.

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.

Wait a moment. Whilst there are certainly very, very good reasons why you
*should* program for things that have a firm chance of a definite maybe of
happening, let's just look at the effort involved here in the two
techniques:

Technique 1 (your way) requires you to include the <stdlib.h> header 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?

 

[Richard Bos]

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]

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.[/QUOTE]

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]

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.

[/QUOTE]

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

 

[Ryan Ply]

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

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:



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!

 

[Mark McIntyre]

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]

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.

 

[Christopher Layne]

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]

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:

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.h> from a given
source if it turns out not to be required therein.