Dan P <dan### [at] yahoocom> wrote:
> >   Usually you should return EXIT_SUCCESS from main() if you want to be
> > sure of portability.
> >   EXIT_SUCCESS is *usually* 0, but the standard does not specify that.

> I did not know that! I'll remember that!!!

  It's way too common that people don't care about the return value of
the program they are making (specially if it's a command-line program).
  Often they return EXIT_SUCCESS and EXIT_FAILURE because they have been
taught to do so, but they don't really understand why they should do so.
  In the worst case they don't care what the program returns and they
for example *always* return 0 regardless of the cause of the program
termination, or what is a lot worse, always return a value different
from 0.

  It is important that a program returns EXIT_FAILURE when it could not
do what it was supposed to do (eg. bad command-line parameters, couldn't
open an input file, etc). It's also important to return EXIT_SUCCESS when
the program was able to correctly perform its task and everything went fine.

  One could ask "why is it so important? If I run the program from the
command line, what does it matter what it returns? I will see from its
printout if it went well or wrong."

  However, programs are not always run from the command line. One common
usage of command-line programs where the correct return value is crucial
is when running it from a Makefile.
  The make program will *stop* if the program returns an error code
(usually a value different from 0). Thus if the program returns an error
code needlessly it will make the program unusable in a Makefile.
  It's also important for the program to return an error code when an
error happens: If it always returns success, make will not know to
stop and will think the program was successful and will continue (thus
potentially causing all kinds of weird results, the reason of which can
be very hard to find).

> > >  fflush(0);
> >
> >   It's 'fflush(stdout);', and it's unneeded anyways.

> Good point on using the variable. I've worked on systems where I had trouble
> with putchar() without flushing, though.

  flushing a stream is necessary when you need to ensure that the output
is really written to its destination at that point (streams are usually
buffered and things may not be written immediately to the destination).
  If it's enough for the output to be written when the program ends then
there's no need to flush explicitly because the compiler will generate
the flushing call at the end of the program anyways (the C standard
actually requires this, AFAIK).

  One example of a useful use of fflush() is when you are printing some
progress information with printf() (using "\r" to go to the beginning
of the line after each update): fflush(stdout) will ensure that the
progress information is actually printed to standard output at that point.

  fflush() shouldn't be called too often because it makes the program slow.
For example calling fflush() after each output character is madness unless
there's a really good reason for you to do so... :)

  (By the way, stderr is usually unbuffered, which means that it's in
practice flushed after each character. This means that stderr should not
be used for printing megabytes of data. :) )

  And by the way, fflush() takes a FILE pointer, not a file descriptor.
When you give it a 0 you are actually giving it a NULL pointer.

> Oh, you're right -- that was a bug on my part. I used unsigned so I can use
> up to 65535 instead of being stuck with half that.

  Which 10-years old system are you using where ints are 16-bit? ;)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message