any error in the code – C / C++

  c

Q(Question):

int main()
{
int *p;
p = (int*)malloc(sizeof(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 )

A(Answer):

In article <65*************@mid.individual.net>,
Martin Ambuhl <ma*****@earthlink.netwrote:

>pa********@hotmail.com wrote:

> int main()
{
int *p;
p = (int*)malloc(sizeof(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.

A(Answer):

On Apr 1, 2:47*pm, "parag_p…@hotmail.com" <parag_p…@hotmail.com>
wrote:

* int main()
* {
* * * int *p;
* * * p = (int*)malloc(sizeof(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

A(Answer):

Ja*************@gmail.com said:

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

>int main()
{
int *p;
p = (int*)malloc(sizeof(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

A(Answer):

In article <PO******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>Ja*************@gmail.com said:

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

>>int main()
{
int *p;
p = (int*)malloc(sizeof(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()?

A(Answer):

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

A(Answer):

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_application} 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?

A(Answer):

Antoninus Twink <no****@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_application} 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).

A(Answer):

Richard Heathfield <rj*@see.sig.invalidwrites:
[…]

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_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
— Antony Jay and Jonathan Lynn, "Yes Minister"

A(Answer):

Ja*************@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

A(Answer):

la************@siemens.com writes:

Ja*************@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.

A(Answer):

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

Ja*************@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.

A(Answer):

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

A(Answer):

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

A(Answer):

In article <8L******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>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

A(Answer):

Richard Heathfield wrote:

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.

Yes, it’s inelegant. But why does it increase compilation time? The time
required to read the headers must be too trivial to be calculated and
included in ‘compilation time’. Or not?


Joe Wright
"Everything should be made as simple as possible, but not simpler."
— Albert Einstein —

A(Answer):

Joe Wright wrote:

Richard Heathfield wrote:

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

Yes, it’s inelegant. But why does it increase compilation time? The time
required to read the headers must be too trivial to be calculated and
included in ‘compilation time’. Or not?

It may even improve compile time if the compiler supports precompiled
headers.


Ian Collins.

A(Answer):

On Tue, 1 Apr 2008 12:11:44 -0400, la************@siemens.com wrote in
comp.lang.c:

Ja*************@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

Ahem.

Perhaps because the C standard does not, and cannot, impose
requirements on operating systems. So the C standard neither
guarantees nor even specifies what the result on the platform might be
if a C executable terminates without releasing dynamically allocated
memory.

And in the real world, at least some early versions of MS-DOS were
prone to displaying an error message along the lines of "Memory Arena
Corrupted, System Halted" and locking up if programs exited without
releasing allocated memory.

I wouldn’t be surprised if there were some oddball niche operating
systems around today that might have problems, even if popular desktop
OS’s handle the situation.


Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

A(Answer):

Harald van D?k said:

<snip>

However, even then it’s possible to disable this by adding -fno-builtin
to the compiler options.

….which is all completely off-topic here, of course (but that hasn’t
stopped me from gratefully adding -fno-builtin to my makefile generator).


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

A(Answer):

On Apr 2, 11:14*am, Richard Heathfield <r…@see.sig.invalidwrote:

Harald van D?k said:

<snip>

However, even then it’s possible to disable this by adding -fno-builtin
to the compiler options.

…which is all completely off-topic here, of course (but that hasn’t
stopped me from gratefully adding -fno-builtin to my makefile generator).


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

HI All
Thank you all for letting so many views out on this .

I also wanted to know, whether there is any error in the way the
function Error is defined. Well, if it exists from this function , it
definitely measn that we dont need to free anything , do we>

Even after the returned value is a NULL;
I am giving the full code here
#include <stdlib.h>
#include <stdio.h>
void Error(char* s)
{
printf(s);
return;
}

int main()
{
int *p;
p = (int*)malloc(sizeof(int));
if(p == NULL)
{
Error("Could not allocate the memory\n");
Error("Quitting….\n");
exit(1);
}
else
{
/*some stuff to use p*/
}
return 0;
}

A(Answer):

pa********@hotmail.com said:

<snip>

I also wanted to know, whether there is any error in the way the
function Error is defined. Well, if it exists from this function , it
definitely measn that we dont need to free anything , do we>

Even after the returned value is a NULL;
I am giving the full code here
#include <stdlib.h>
#include <stdio.h>
void Error(char* s)
{
printf(s);
return;
}

Careful. Think about what printf will think, if s contains any % signs!

What do you think of this replacement?

void error(FILE *fp, const char *s)
{
fprintf(fp, "Error: %s\n", s);
}

int main()
{
int *p;
p = (int*)malloc(sizeof(int));

p = malloc(sizeof *p);

But why allocate memory for a single int? Wouldn’t it be easier to do:

int i;

if(p == NULL)
{
Error("Could not allocate the memory\n");
Error("Quitting….\n");
exit(1);

exit(EXIT_FAILURE);

}
else
{
/*some stuff to use p*/

….followed by free(p);

}
return 0;
}


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

A(Answer):

"pa********@hotmail.com" wrote:

>
int main() {

should read "int main(void) {".

int *p;
p = (int*)malloc(sizeof(int));

should have no cast. The cast is not needed, and is hiding the
critical error of failing to #include <stdlib.h>

if (p == NULL) {
Error("Could not allocate the memory\n");
Error("Quitting….\n");
exit(1);

The functions "Error" and "exit" are not declared. Error is not a
standard C function. exit is accessed via #include <stdlib.h>.
The argument ‘1’ for it is not legitimate, the only legal arguments
are 0, EXIT_SUCCESS and EXIT_FAILURE. Again, the EXIT_* values are
declared in <stdlib.h>

}

Here you are missing a "return 0". main returns an int (same as
exit). Do so.


[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


Posted via a free Usenet account from http://www.teranews.com

A(Answer):

In article <8d********************************@4ax.com>,

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

>Perhaps because the C standard does not, and cannot, impose
requirements on operating systems. So the C standard neither
guarantees nor even specifies what the result on the platform might be
if a C executable terminates without releasing dynamically allocated
memory.

If it can’t impose requirements on operating systems, it can’t specify
what the result might be if a program terminates after releasing
dynamically allocated memory.

— Richard

:wq

A(Answer):

Joe Wright wrote:

Richard Heathfield wrote:

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

Yes, it’s inelegant. But why does it increase compilation time? The
time required to read the headers must be too trivial to be
calculated and included in ‘compilation time’. Or not?

I’m now using #include "stdhdr.h", which includes all 24 C99 headers, and
the compilation time is still pretty much zero for an empty program.

Total about 3000 lines, compared with some 20000 lines for Windows header
files for example.

Only problem is, when posting code, I need to pick and choose the include
files that are used. Now why didn’t something like my stdhdr.h get into the
standard?

And I think my idea is much more elegant than having having some arbitrary,
and slightly different, subset of the 24 headers at the start of every
module, to add to the maintenance work.


Bart

A(Answer):

Nick Keighley wrote:

On 2 Apr, 08:29, "parag_p…@hotmail.com" <parag_p…@hotmail.com>
wrote:

>On Apr 2, 11:14 am, Richard Heathfield <r…@see.sig.invalidwrote:

<snip>

>{
printf(s);

this function seems to do almost nothing. It could give
odd behaviour if s contained any % symbols. Use

printf "%s\n", s);

rather
printf("%s\n", s);
but better
fprintf(stderr,"%s\n", s);
After all it is supposed to print en error message

Bye, Jojo

A(Answer):

On Apr 2, 5:56*pm, "Joachim Schmitz" <nospam.j…@schmitz-digital.de>
wrote:

Nick Keighley wrote:

On 2 Apr, 08:29, "parag_p…@hotmail.com" <parag_p…@hotmail.com>
wrote:

On Apr 2, 11:14 am, Richard Heathfield <r…@see.sig.invalidwrote:

*<snip>

{
printf(s);

this function seems to do almost nothing. It could give
odd behaviour if s contained any % symbols. Use

* * printf "%s\n", s);

rather
* * * printf("%s\n", s);
but better
* * * fprintf(stderr,"%s\n", s);
After all it is supposed to print en error message

Bye, Jojo

Thank you all,

It was a valuable learning experience. But does including strhdr.h
make the compilation procedure costlier

or the compiler has any optimizations like the
#ifndef __STDHDR.H__

-Parag

A(Answer):

pa********@hotmail.com wrote:

On Apr 2, 5:56*pm, "Joachim Schmitz" <nospam.j…@schmitz-digital.de>
wrote:

>Nick Keighley wrote:

On 2 Apr, 08:29, "parag_p…@hotmail.com" <parag_p…@hotmail.com>
wrote:
On Apr 2, 11:14 am, Richard Heathfield <r…@see.sig.invalid>
wrote:

<snip>

>{
printf(s);

this function seems to do almost nothing. It could give
odd behaviour if s contained any % symbols. Use

printf "%s\n", s);

rather
printf("%s\n", s);
but better
fprintf(stderr,"%s\n", s);
After all it is supposed to print en error message

Bye, Jojo

Thank you all,

It was a valuable learning experience. But does including strhdr.h
make the compilation procedure costlier

or the compiler has any optimizations like the
#ifndef __STDHDR.H__

No standard header includes any other standard header, and yes,
your "stdhdrs.h" should probably use the customary include guard.

LEAVE A COMMENT