any error in the code

[parag_paul@hotmail.com]

int main()
{
int *p;
p = (int*)malloc(si zeof(int));
if(p == NULL)
{
Error("Could not allocate the memory\n");
Error("Quitting ....\n");
exit(1);
}


Is it correct to check in gcc , ( compare with NULL )

[Kenny McCormack]

Re: any error in the code

In article <65eherF2f094rU 1@mid.individua l.net>,
Martin Ambuhl <mambuhl@earthl ink.netwrote:

>parag_paul@hot mail.com wrote:

> int main()
> {
> int *p;
> p = (int*)malloc(si zeof(int));
> if(p == NULL)
> {
> Error("Could not allocate the memory\n");
> Error("Quitting ....\n");
> exit(1);
> }
>>
>>
>Is it correct to check in gcc , ( compare with NULL )

>
>Your program is broken in oh-so-many ways. It is not correct with gcc
>or with any other compiler for C. Compare it to the following:

The great Antonious Twink. Knows all. Tells all.

[Jack.Thomson.v3@gmail.com]

Re: any error in the code

On Apr 1, 2:47 pm, "parag_p...@hot mail.com" <parag_p...@hot mail.com>
wrote:

  int main()
  {
      int *p;
      p = (int*)malloc(si zeof(int));

Do not type cast malloc as the C standard states.

      if(p == NULL)
      {
          Error("Could not allocate the memory\n");
          Error("Quitting ....\n");
          exit(1);
      }
>
Is it correct to check in gcc , ( compare with NULL )

Always free the dynamically allocated memory before exitting from the
program



~Jack
--------------------------------------

http://programmingsite.googlepages.com

[Richard Heathfield]

Re: any error in the code

Jack.Thomson.v3 @gmail.com said:

On Apr 1, 2:47 pm, "parag_p...@hot mail.com" <parag_p...@hot mail.com>
wrote:

>int main()
>{
>int *p;
>p = (int*)malloc(si zeof(int));

Do not type cast malloc as the C standard states.

The C Standard does not say either to cast the value returned by malloc, or
not to cast that value.

Casting the value returned by malloc is pointless and can hide a bug, but
it is neither forbidden nor compulsory.

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.

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

[Kenny McCormack]

Re: any error in the code

In article <PO2dnYb_kfjmtm _anZ2dnUVZ8tDin Z2d@bt.com>,
Richard Heathfield <rjh@see.sig.in validwrote:

>Jack.Thomson.v 3@gmail.com said:
>

>On Apr 1, 2:47 pm, "parag_p...@hot mail.com" <parag_p...@hot mail.com>
>wrote:

>>int main()
>>{
>>int *p;
>>p = (int*)malloc(si zeof(int));

>Do not type cast malloc as the C standard states.

>
>The C Standard does not say either to cast the value returned by malloc, or
>not to cast that value.
>
>Casting the value returned by malloc is pointless and can hide a bug, but
>it is neither forbidden nor compulsory.
>
>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.

Well, then. We've got that settled. Good show, old man!

Shall we move on now to how to prototype main()?

[Chris Dollin]

Re: any error in the code

Kenny McCormack wrote:

Shall we move on now to how to prototype main()?

I find the best prototype `main` is

#include <stdio.h>

int main(void)
{
printf( "#{my_applicati on} v0.1" );
return 0;
}

It's extensible in so many different directions.

--
"Your world, Colonel, and I wish you the best of it!" /Witch World/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Antoninus Twink]

Re: any error in the code

On 1 Apr 2008 at 13:22, Chris Dollin wrote:

Kenny McCormack wrote:
>

>Shall we move on now to how to prototype main()?

>
I find the best prototype `main` is
>
#include <stdio.h>
>
int main(void)
{
printf( "#{my_applicati on} v0.1" );
return 0;
}
>
It's extensible in so many different directions.

Interesting! I often start with
int main(void)
but then later find I need to process command-line arguments, so I
change it to
int main(int argc, char **argv).

Sometimes for quick throwaway programs, I naughtily use implicit int and
just have
main().

Does anyone else have any insights to share on this important point?

[Richard]

Re: any error in the code

Antoninus Twink <nospam@nospam. invalidwrites:

On 1 Apr 2008 at 13:22, Chris Dollin wrote:

>Kenny McCormack wrote:
>>

>>Shall we move on now to how to prototype main()?

>>
>I find the best prototype `main` is
>>
> #include <stdio.h>
>>
> int main(void)
> {
> printf( "#{my_applicati on} v0.1" );
> return 0;
> }
>>
>It's extensible in so many different directions.

>
Interesting! I often start with
int main(void)
but then later find I need to process command-line arguments, so I
change it to
int main(int argc, char **argv).
>
Sometimes for quick throwaway programs, I naughtily use implicit int and
just have
main().
>
Does anyone else have any insights to share on this important point?

I think it should all be on one line to make debugging impossible and
encourage people to get their code right first time like Chuck and
others. It will also compile faster with no white space ....

(ps I always include argc, argv in the main).

[Keith Thompson]

Re: any error in the code

Richard Heathfield <rjh@see.sig.in validwrites:
[...]

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.hany time you call malloc, whether
you cast it or not.

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

[lawrence.jones@siemens.com]

Re: any error in the code

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

[Richard]

Re: any error in the code

lawrence.jones@ siemens.com writes:

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

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: any error in the code

On Tue, 01 Apr 2008 12:11:44 -0400, lawrence.jones wrote:

Jack.Thomson.v3 @gmail.com wrote:

>Always free the dynamically allocated memory before exitting from the
>program

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

[Bartc]

Re: any error in the code

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 disadvantage of just including *all* of the standard C headers
(or more likely creating a single header file that includes them)?

--
Bart

[Richard Heathfield]

Re: any error in the code

Bartc said:

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

[Richard Tobin]

Re: any error in the code

In article <8LadnTHF44NE5W _anZ2dneKdnZydn Z2d@bt.com>,
Richard Heathfield <rjh@see.sig.in validwrote:

>What's the disadvantage 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.

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

-- Richard
--
:wq