C - any error in the code

Author

any error in the code

parag_paul@hotmail.com

2008-04-01, 7:58 am

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 )

Antoninus Twink

2008-04-01, 7:58 am

On 1 Apr 2008 at 9:47, parag_paul@hotmail.com wrote:
> int main()
> {
> int *p;
> p = (int*)malloc(sizeof(int));

This is fine, though people round here hate this malloc idiom with a
passion.

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

Yes. if(!p) is also fine, and saves several characters.

Before long, someone will be along to tell you that Error() isn't a
standard function, and that 1 isn't a portable argument to exit().

Martin Ambuhl

2008-04-01, 7:58 am

parag_paul@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:

#include <stdlib.h> /* mha: for malloc, exit, and NULL.
Your code implicitly declares
(incorrectly) malloc to return an
int if you don't have a C99
compiler. With a C99 compiler your
code is illegal rather than
erroneous */
#include <stdio.h> /* mha: for my macro to give your
'Error' identifier a meaning. */

/* mha: Since you use the completely undefined function 'Error' I have
supplied a macro for it. But be careful about identifiers beginning
with 'E' */
#define Error(s) fputs(s,stderr)

int main(void)
{
int *p;
p = malloc(sizeof *p); /* mha: Your original line 'p = (int *)
malloc(sizeof(int));' is not wrong,
but it is not best. The cast is
superfluous typing practice, and
useof sizeof(int) supposes that the
variable p will never have its type
changed. */
if (p == NULL) {
Error("Could not allocate the memory\n");
Error("Quitting....\n");
exit(EXIT_FAILURE); /* mha: your argument to exit, 1, has
no portably efined meaning. I have
replaced it with one of thr three
having a defined meaning, which are
0, EXIT_SUCCESS, and EXIT_FAILURE */

}

free(p); /* mha: always free any memory you
dynamically allocate. */

return 0; /* mha: You promised to return an int,
so do so. Without this the program
status on exit is not portably
defined unless you have a C99
compiler (gcc isn't one, even in C99
mode) */
} /* mha: added a closing brace. */

Kenny McCormack

2008-04-01, 7:58 am

In article <65eherF2f094rU1@mid.individual.net>,
Martin Ambuhl <mambuhl@earthlink.net> wrote:
>parag_paul@hotmail.com wrote:
>
>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

2008-04-01, 7:58 am

On Apr 1, 2:47=A0pm, "parag_p...@hotmail.com" <parag_p...@hotmail.com>
wrote:
> =A0 int main()
> =A0 {
> =A0 =A0 =A0 int *p;
> =A0 =A0 =A0 p =3D (int*)malloc(sizeof(int));
Do not type cast malloc as the C standard states.
> =A0 =A0 =A0 if(p =3D=3D NULL)
> =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 Error("Could not allocate the memory\n");
> =A0 =A0 =A0 =A0 =A0 Error("Quitting....\n");
> =A0 =A0 =A0 =A0 =A0 exit(1);
> =A0 =A0 =A0 }
>
> 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

2008-04-01, 7:58 am

Jack.Thomson.v3@gmail.com said:

> On Apr 1, 2:47 pm, "parag_p...@hotmail.com" <parag_p...@hotmail.com>
> wrote:
> 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

2008-04-01, 7:58 am

In article <PO2dnYb_kfjmtm_anZ2dnUVZ8tDinZ2d@bt.com>,
Richard Heathfield <rjh@see.sig.invalid> wrote:
>Jack.Thomson.v3@gmail.com said:
>
>
>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

2008-04-01, 7:00 pm

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

Antoninus Twink

2008-04-01, 7:00 pm

On 1 Apr 2008 at 13:22, Chris Dollin wrote:
> Kenny McCormack wrote:
>
>
> 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?

Richard

2008-04-01, 7:00 pm

Antoninus Twink <nospam@nospam.invalid> writes:

> On 1 Apr 2008 at 13:22, Chris Dollin wrote:
>
> 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

2008-04-01, 7:00 pm

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"

lawrence.jones@siemens.com

2008-04-01, 7:00 pm

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

2008-04-01, 7:00 pm

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.

Richard Heathfield

2008-04-01, 7:00 pm

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

Harald van Dĳk

2008-04-01, 7:00 pm

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.

Keith Thompson

2008-04-01, 7:00 pm

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"

Richard Heathfield

2008-04-01, 7:00 pm

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

Bartc

2008-04-01, 7:00 pm

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 di

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

--
Bart

Richard Heathfield

2008-04-01, 7:00 pm

Bartc said:

> Richard Heathfield wrote:
>
>
> What's the di

vantage 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

2008-04-01, 7:00 pm

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

[color=darkred]
>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

Eric Sosman

2008-04-01, 9:58 pm

Chris Dollin wrote:
> Kenny McCormack wrote:
>
>
> 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.

For the ultimate in extensibility, I do not think
this IOCCC entry can be surpassed:

#include "/dev/tty"

(Questions of conformance are surprisingly difficult
to resolve.)

--
Eric Sosman
esosman@ieee-dot-org.invalid

Joe Wright

2008-04-01, 9:58 pm

Richard Heathfield wrote:
> Bartc said:
>
>
> 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 ---

Ian Collins

2008-04-01, 9:58 pm

Joe Wright wrote:
> Richard Heathfield wrote:
>
> 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.

Jack Klein

2008-04-02, 8:00 am

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

> 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

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

Keith Thompson

2008-04-02, 8:00 am

Richard Heathfield <rjh@see.sig.invalid> writes:
> Keith Thompson said:
[...]
>
> 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.

<OT>

Perhaps it's time for an upgrade. Consider the following program,
which I presume is the kind of thing you're talking about (note the
missing "#include <string.h>"):

#include <stdio.h>
int main(void)
{
char *s = "hello";
size_t len = strlen(s);
printf("len = %d\n", (int)len);
return 0;
}

With gcc 3.4.4, "-Wall" triggers "warning: implicit declaration of
function `strlen'".

With gcc 4.1.3, even with no options I get "warning: incompatible
implicit declaration of built-in function 'strlen'".

</OT>

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

Harald van Dĳk

2008-04-02, 8:00 am

On Tue, 01 Apr 2008 21:54:08 -0700, Keith Thompson wrote:
> Richard Heathfield <rjh@see.sig.invalid> writes:
> [...]
>
> <OT>
>
> Perhaps it's time for an upgrade. Consider the following program, which
> I presume is the kind of thing you're talking about (note the missing
> "#include <string.h>"):
>
> #include <stdio.h>
> int main(void)
> {
> char *s = "hello";
> size_t len = strlen(s);
> printf("len = %d\n", (int)len);
> return 0;
> }
>
> With gcc 3.4.4, "-Wall" triggers "warning: implicit declaration of
> function `strlen'".
>
> With gcc 4.1.3, even with no options I get "warning: incompatible
> implicit declaration of built-in function 'strlen'".

GCC 2.x used to have a bug/feature where strlen is a predefined
identifier, and warnings for implicit declarations of predefined
identifiers were not emitted.

$ cat test.c
main() { return strlen(""); }
$ gcc-2.95.3 -c -Wall test.c
test.c:1: warning: return-type defaults to `int'

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

$ gcc-2.95.3 -c -Wall test.c -fno-builtin
test.c:1: warning: return-type defaults to `int'
test.c: In function `main':
test.c:1: warning: implicit declaration of function `strlen'

Oddly enough, this _does_ generate a warning:

$ cat test.c
main() { return strlen(""); }
$ gcc-2.95.3 -c test.c
test.c: In function `main':
test.c:1: warning: built-in function `strlen' used without declaration

> </OT>

Richard Heathfield

2008-04-02, 8:00 am

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

parag_paul@hotmail.com

2008-04-02, 8:00 am

On Apr 2, 11:14=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
> Harald van D?k said:
>
> <snip>
>
>
> ...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 =3D (int*)malloc(sizeof(int));
if(p =3D=3D NULL)
{
Error("Could not allocate the memory\n");
Error("Quitting....\n");
exit(1);
}
else
{
/*some stuff to use p*/
}
return 0;
}

Richard Heathfield

2008-04-02, 8:00 am

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

Nick Keighley

2008-04-02, 8:00 am

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

<snip>
[color=darkred]

don't quote signatures (the bit after "-- ")

[color=darkred]
> Thank you all for letting so many views out on this .

some of which you ignore...

> I also wanted to know, whether there is any error in the way the
> function Error is defined.

no real errors...

> Well, if it exists from this function , it
> definitely measn that we dont need to free anything , do we
exists -> exits?

which is "this function"? Error()? or main()?
Since Error() makes no sense (exiting from Error() doesn't
make the blindest bit of difference) I assume you mean main().
Well yes any decent OS will clean up the memory on exit.
But it is a bad habbit to get into. What if you move the code
to a subroutine of a larger program?

The code you quote has absolutly no need of a malloc() (just
declare an int) hence it doesn't need a free()

> Even after the returned value is a NULL;

free(NULL) is harmless. It does nothing.

> =A0 I am giving the full code here

> =A0 #include <stdlib.h>
> =A0 #include <stdio.h>

I put a blank line here for readability

> =A0 void Error(char* s)

it is unusual to start a function name with an
upper case letter.

> =A0 {
> =A0 =A0 =A0 printf(s);

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

printf "%s\n", s);
or
puts (s);

> =A0 =A0 =A0 return;
> =A0 }
>
> =A0 int main()

int main (void)

is better

> =A0 {
> =A0 =A0 =A0 int *p;
> =A0 =A0 =A0 p =3D (int*)malloc(sizeof(int));

DON'T CAST MALLOC!

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

don't use exit(1)

> =A0 =A0 =A0 }
> =A0 =A0 =A0 else
> =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 /*some stuff to use p*/
> =A0 =A0 =A0 }
> =A0 =A0 =A0 return 0;
> =A0 }

--
Nick Keighley

CBFalconer

2008-04-02, 8:00 am

"parag_paul@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

Richard Tobin

2008-04-02, 8:00 am

In article <8dt5v312qia63jq10oaoubtjj2fseibrje@4ax.com>,

[color=darkred]
>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

Bartc

2008-04-02, 8:00 am

Joe Wright wrote:
> Richard Heathfield wrote:
>
> 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

Joachim Schmitz

2008-04-02, 8:00 am

Nick Keighley wrote:
> On 2 Apr, 08:29, "parag_p...@hotmail.com" <parag_p...@hotmail.com>
> wrote:
>
<snip>
>
> 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

parag_paul@hotmail.com

2008-04-02, 10:07 pm

On Apr 2, 5:56=A0pm, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
wrote:
> Nick Keighley wrote:
>
> =A0<snip>
>
>
>
> rather
> =A0 =A0 =A0 printf("%s\n", s);
> but better
> =A0 =A0 =A0 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

santosh

2008-04-02, 10:07 pm

parag_paul@hotmail.com wrote:

> On Apr 2, 5:56_pm, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
> wrote:
>
> 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.

Sponsored Links