any error in the code

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

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

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.

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

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"

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>

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

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

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

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>
 

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


> 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