any error in the code

Richard Heathfield <rjh@see.sig.invalid> writes:
[...]
> Rather more importantly, if you *must* cast the result of malloc for some
> silly reason, make sure that you #include <stdlib.h>, because (in C90) the
> cast removes the obligation on your implementation to diagnose a symptom
> of failing to include that header.

Make sure you #include <stdlib.h> any time you call malloc, whether
you cast it or not.

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Jack.Thomson.v3@gmail.com wrote:
>
> Always free the dynamically allocated memory before exitting from the
> program

Why?  Any properly functioning OS will do that automatically after the
program exits, usually much more efficiently than the program can.

-Larry Jones

I don't want to learn this!  It's completely irrelevant to my life! -- Calvi
n

lawrence.jones@siemens.com writes:

> Jack.Thomson.v3@gmail.com wrote: 
>
> Why?  Any properly functioning OS will do that automatically after the
> program exits, usually much more efficiently than the program can.
>
> -Larry Jones
>
> I don't want to learn this!  It's completely irrelevant to my life! --
> Calvin

Don't go there (but do delimit your .sig). Before you know it we'll have
the usual flame war about the effectiveness of checking the return value
from malloc for itty bitty mallocs of a few bytes on an OS like Linux
which nearly always says "success" anyway.

Keith Thompson said:

> Richard Heathfield <rjh@see.sig.invalid> writes:
> [...] 
>
> Make sure you #include <stdlib.h> any time you call malloc, whether
> you cast it or not.

English is weird, isn't it? Yes, you're right. I know you know I know
better, but it sure doesn't look that way in the quoted text, does it?

To make this crystal clear to the OP:

1) regardless of whether you choose to cast malloc, it is a function that
returns void *. The prototype for malloc is void *malloc(size_t) - and it
is supplied in <stdlib.h>
2) in the absence of a prototype (or rather, a declaration, of which a
prototype is merely a special case) for any function call - even calls of
standard library functions - the compiler is obliged to assume that the
called function returns int. Therefore, you do actually need the
declaration, which means you need to #include <stdlib.h>
3) in normal use, if you forget to do this, the implementation won't have a
declaration for malloc, so it will assume malloc returns an int. It will
then see that you're assigning this (int, as the implementation sees it)
result to a pointer, which isn't allowed, so it will diagnose the problem
and you have your chance to put it right by #include <stdlib.h>
4) unfortunately, it *is* legal to assign an int to a pointer if you cast
the int first, to the appropriate pointer type. So casting malloc's result
actually works against you by suppressing an error message that you would
otherwise get if you failed to #include <stdlib.h>

Bottom line: ALWAYS include the appropriate standard header for ANY
standard function you use, and NEVER cast. (Actually, there *are* a few
times when you should use a cast, but they are vanishingly few.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

On Tue, 01 Apr 2008 12:11:44 -0400, lawrence.jones wrote:
> Jack.Thomson.v3@gmail.com wrote: 
>
> Why?

Because keeping it around makes it harder to figure out if you have a
memory leak somewhere.

> Any properly functioning OS will do that automatically after the
> program exits, usually much more efficiently than the program can.

You could also guard the freeing with #if FREE_ON_EXIT, and only enable
it when debugging.

Richard Heathfield <rjh@see.sig.invalid> writes:
[...]
> 2) in the absence of a prototype (or rather, a declaration, of which a
> prototype is merely a special case) for any function call - even calls of
> standard library functions - the compiler is obliged to assume that the
> called function returns int. Therefore, you do actually need the
> declaration, which means you need to #include <stdlib.h>
[...]

The above is correct for C90.  In C99, a declaration is required, and
its lack triggers a diagnostic.

But you (that's a generic "you") shouldn't assume that the compiler
either will or will not warn you about incorrect calls.  It's up to
the programmer to get this right in the first place.  The best way to
do that is (a) #include <stdlib.h>, and (b) don't cast the result of
malloc().  Once you develop that habit, there's a better chance that
the compiler will inform you if you mess up now and then.

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson said:

> Richard Heathfield <rjh@see.sig.invalid> writes:
> [...] 
> [...]
>
> The above is correct for C90.

Right.

> In C99, a declaration is required, and
> its lack triggers a diagnostic.

Call me when I care. :-)

> But you (that's a generic "you") shouldn't assume that the compiler
> either will or will not warn you about incorrect calls.  It's up to
> the programmer to get this right in the first place.

Well, you're right - I'm forever forgetting to #include <string.h>, and
being bluntly reminded of the fact only when I compile the code on a Win32
box, because my Linux-based compiler simply isn't interested, no matter
how many diagnostic switches I set, so I ought to know by now that I can't
rely on the compiler to diagnose me out of trouble - but it's a
non-trivial problem (in the general case); it's easy to forget to add a
header, and saying "Don't Do That" doesn't really help much.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:

> Well, you're right - I'm forever forgetting to #include <string.h>,
> and being bluntly reminded of the fact only when I compile the code
> on a Win32 box

What's the divantage of just including *all* of the standard C headers
(or more likely creating a single header file that includes them)?

--
Bart

Bartc said:

> Richard Heathfield wrote:
> 
>
> What's the divantage of just including *all* of the standard C headers
> (or more likely creating a single header file that includes them)?

Partly, it increases compilation time. But I think most people's *real*
objection to it is that it's inelegant.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

In article <8LadnTHF44NE5W_anZ2dneKdnZydnZ2d@bt.com>,
Richard Heathfield  <rjh@see.sig.invalid> wrote:
 

>Partly, it increases compilation time. But I think most people's *real*
>objection to it is that it's inelegant.

On the other hand, it would probably detect certain errors quicker.

-- Richard
--
:wq