The local variable szNewString[] is not initialized.

On Cygwin, there was trash in front of the printed string.

Seems like it would always be the case. I would not think
the compiler could take the initiative to initialize my
local variables. If it did, it might take unnecessary
execution time. Even if it did, the author should not
leave these uninitialized.

I added:

Uninitialized variables can be the source of many bugs...

When I compile "cc -c appendall.c" under Fedora11 with all the defaults, I get an error complaining that there are, "incompatible implicit declarations of built-in functions" strcat and strlen.

The offending lines have the code:

strlen( szReturnBuffer ) + strlen( iArgs[i] )

and:

strcat( szReturnBuffer, iArgs[i] )

Now since these variables are declared as char * iArgs[] and
char * szReturnBuffer, these errors look simply wrong, unless the detault is so pedantic a version that it won't tolerate interchange of arrays and pointers in this context.

But what is the problem really, here?

Just in case the reader does not remember the defaults for Fedora11, gcc version displays:

gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)

By design, the C programmer usually does not need to know the answer to this question. This is an example of the principle called "information hiding", a principle very basic to all object oriented programming, though it actually predates OOP.

However, the usual place for such data is on the stack: most modern CPU architectures make it easy to store lots of variables on the same stack used for return addresses. Just don't make them TOO big!

Then again, a few temporary variables may actually get stored in CPU registers. But this is an optimization, so it is highly dependent on 1) what level of optimization you compile for and 2) the code generator of your compiler.

Again, by design, the programmer does not need to know. Except possibly for very special purposes, such as optimization.

It turns out the problem is that the program omitted a vital #include: somewhere near the top there should be "#include <string.h>". What version of C or of <stdio.h> was the author using that it already included the right declaration for strlen and strcat? This is NOT standard.

well this is my first post on this forum.. and my sole purpose of joining it was tht to learn c programming in linux!!! can any1 gimme a link or a tutorial to start from basic's of difference between linux and winodws programming!!

im new to the world of c programming !!! and have jus started wid the basics of c.. wanna learn together in linux also !!!

thanks for this one ..
got to know more about ,make file and
i cleared some of my doubts

Exactly what I was looking for.
I was lost in a world of compiler and linker option switches and where the .h files were located and never guessed that it was all known to the system.

I have umpteen years of experience but it's 20 years since I used unix and really very limited Intel experience.

Anyway thanks so much

I want to read data from serial port without using carriage return
please tell me how to do it

Je to super. Zacinam l linuxmandrake a super. Diky moc za názorna témata

Good tutorial. Most source codes are too large for a beginner. I never knew how to create a makefile. The tutorial is missing 'configure' script an important part of most *nix source codes.

This is my first post, and I must be negative. I did extensive C programming 20 years ago, and typed in the appendall source code as entered. As others have commented, this code has several errors: missing include file statements and uninitialized strings. Maybe there is now a hand-holding compiler that can make sense of this code, but the example does not work using gcc/Ubuntu. This could be a very discouraging experience for a novice. The tutorial should either be corrected or removed.