C Programming

Sun May 9 16:46:10 UTC 2004

On Sun, May 09, 2004 at 08:34:28AM -0500, Jeff Vian wrote:
> fredex wrote:
> >On Sat, May 08, 2004 at 10:46:37PM -0400, Wade Chandler wrote:
> >>Gene Heskett wrote:
> >>>On Saturday 08 May 2004 06:27, Trevor McNamara wrote:
> >>>>Hello,
> >>>>
> >>>>I am unsure if this is the correct post for this sort of question.
> >>>>If not can someone please direct me in the right direction?
> >>>>
> >>>>I was wondering if anyone would know anywhere that I can download a
> >>>>guide for an INTRO to C programming, As I would like to know C, then
> >>>>I can understand some of the source code for UNX/LINUX?
> >>>>
> >>>>I have done a little bit of VB programming but nothing in C.
> >>>>
> >>>>Any help on this would be great.
> >>>>
> >>>>Thanks.
> >>>>       
> >>>I think most of what I have came from the bookstores.  I've got 
> >>>probably 500+ dollars in so-called C textbooks on the shelf right 
> >>>now.
> >>>
> >>>Start with the one from Herbert Schildt, then fill in the gaps with 
> >>>     
> >>>
> >
> >Not to be a negative-sounding force here, but I would urge you to NOT
> >ever use any of Herbert Schildt's books.
> >
> >Mr. Schildt is a skillful writer, his writing is clear and lucid. He
> >writes books on C and  C++ that very easily and clearly lead you down
> >the path to writing programs that are WRONG. he teaches bad practice in
> >C and C++ in clear and easily understood ways, such that if you follow
> >his advice you will learn his bad habits. one minor example is that he
> >is one of the many people who incorrectly teach that it is permissible
> >to declare main() as being of type void:
> >	void main (void)
> >		{
> >		...
> >		}
> >A little web searching, or spending a little time on groups.google.com
> >reading comp.lang.c will find you plenty of examples of why his books
> >are not a good way to learn C or C++. You can learn, in the same way,
> >of many other books that do teach the language(s) correctly.
> > 
> >
> 
> Please explain why main cannot be of type void.

1. Because the ANSI/ISO standard for the C language requires that main
returns int.

2. And if that isn't good enough for you, if you don't care about
standards, look at the practical implications. When you write a function:

	int func1()
		{
		int func2();
		return func2();
		}
	int func2()
		{
		return 3;
		}
you control what func1 expects func2 to return. If you want to change func2
to return something else, you can do so simply by changing the prototype
for func2 inside func1.

However, you do not control the code that calls main(). That code, assuming
it follows the C language standard, expects main() to return an integer.
If you declare main differently, you're then returning something other
than what the calling routine expects. Which may or may not "work" (for
some definitions of the word), but it is NEVER correct.
> 
> Unless it is returning a value [ void main () ] or receiving a value [ 
> void main( argv, argc ) ] , it should be void. 

Nope.

> Main should be declared as any function within C.  It should be typed to 
> returhn a value *if* it does, and to accept parameters *if needed*.

No. Main is defined by the language standard as returning int and accepting
two arguments (of type integer, and char **). anything else is an error.

You can ignore the two parameters if you intend not to use them by 
delcaring a void parameter list, but they are still passed to it by its
caller. but you ignore its return type at your own peril.

> 
> While I agree main is most often typed to int for the purpose of 
> returning a value designating completion with no errors or an error, 
> there is no *requirement* for that.

ah, but there is. Again, the language standard requires that main return
an integer.

So "why", you ask, "does the standard require main to return int?".
The original C standard was written to "codify existing practice". In many
environments (Unix, MS-DOS, probably other platforms) the return value of 
main is (or can be) used by the invoking program as a success or fail
status indicator. If the program doesn't return such a value the calling
program has no way to find out if hte program ran successfully or not.

True, you CAN write a broken program that doesn't return anything from
main, but it's still going to hand back SOME value to the invoking program
as its status. if you don't provide a value, the code that calls main is
going to return something anyway, most likely some garbage/arbitrary
value it picked up from the place main's return should have been, but 
wasn't (since main is expected to return something but didn't).

Understand, main() is NOT the first code to execute when a C program is
invoked. There's a chunk of "startup code", that is provided by the 
compiler vendor or a linkable library (invisible to the user) that
actually is invoked first, before main(). This code may do little in some
environments, or in other environments it may do a great deal of
stuff. But whatever it does, it (among other things) hands main its two
arguments, and receives an integer back from main. Changing the type of
main in your program does not change this code.

> 
> If you can provide *definitive documentation* of your statement that his 
> teaching is wrong in the requirements for function main() I would like 
> to see it.

See the language standard document.

Or go ask this question in the newsgroup comp.lang.c where you'll either
be ignored as a troll, or else will get flamed, depending on the mood
this week.

Mr. Schildt, for all his skill as a writer (and he is good, no denying
that!), is one (of many) people who perpetuate the myth that it's OK
to play fast and loose with the language standard. The result is that
so many people think that it IS OK to do so. But some day, somewhere in
the future, doing one of these things he teaches will nail your program
to the wall and you won't have a clue why it went wrong.

> 
> > 
> >
> >>>whatever pulls your trigger standing in front of the rack at Barnes & 
> >>>Noble etc.  The first purchase should also include a copy of K&R #2.  
> >>>It should be used as the argument settler in case of confusion.  
> >>>Everything else is just so much, often way more verbose, frosting on 
> >>>the cake.
> >>>
> >>>I looked at some VB code the other night that a friend was working on.  
> >>>Quite a lot being done in 100 lines of code, but I've never seen such 
> >>>a batch of spagetti in my life.  Crap used but not pre-defined all 
> >>>over the place.  Half an hour of talking about it to Jim and I had a 
> >>>headache.  That stuff could convert a well trained programmer into a 
> >>>blithering idiot.  Scarey.
> >>>
> >>Building on this reply....
> >>
> >>I have always liked Herberts books as well.  You can read his C++ bible 
> >>and get up to speed on the necessities of C++ in a couple of 
> >>evenings....in my opinion anyways.  As far as pure C goes I don't know 
> >>... a good starter would be
> >>
> >>The C Programming Language
> >>Brian W.Kernighan and Dennis M. Ritchie(original C creator and Unix 
> >>implementor)
> >>Prentice Hall
> >>ISBN 0-13-110362-8
> >>
> >>Which is one of the best C books because it is essentially the 
> >>instruction manual for the language from two of the original Unix C team 
> >>at Bell labs.
> >>
> >>For info on the book:
> >>http://cm.bell-labs.com/cm/cs/cbook/index.html
> >>
> >>For some history:
> >>http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
> >>
> >>Wade

-- 
---- Fred Smith -- fredex at fcshome.stoneham.ma.us -----------------------------
  "For him who is able to keep you from falling and to present you before his 
 glorious presence without fault and with great joy--to the only God our Savior
 be glory, majesty, power and authority, through Jesus Christ our Lord, before
                     all ages, now and forevermore! Amen."
----------------------------- Jude 1:24,25 (niv) -----------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20040509/8964b08d/attachment-0001.sig>