X-Authentication-Warning: mail.bio.uva.nl: Host biomacI-138.bio.uva.nl [145.18.167.138] claimed to be [145.18.167.138]
Message-Id: <v01540b00b3716032b943@[145.18.167.138]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 26 May 1999 10:35:44 +0200
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From: dlanor AT dds DOT nl (Ronald Landheer)
Subject: Re: srand() or time()
Cc: djgpp AT delorie DOT com
Reply-To: djgpp AT delorie DOT com

>> (and thus causes my
>> program to believe there's an error, which it wisely ignores).
>I think this is a bug in your program.  Programs should only examine
>`errno' if they have other, independent means to indicate that the
>last function call failed.  In the case of `time', it will return -1
>if it fails; *then* you could use `errno' value to find out why it
>failed.
My program watches errno like a hawk (like I do) but only reports errors
when there is one. It uses errno like a kind of progress indicator and a
bool variable called rc to check wether there was an error. For example, in
a file read I would use
  rc = (fread(&buffer, sizeof(buffer), numBlocks, file) == numBlocks);
rc will remain true as long as no errors have accured. Once rc is false, no
errors can occur any more, because no I/O calls can be done (i.e.: I
usually write the line more like this:
  if (rc) rc = (fread(&buffer, sizeof(buffer), numBlocks, file) == numBlocks);
rc is, ofcourse, initialized as true. errno is then used to analyse any
error that may have occured, which is reported with perror() by default.
In debugging, which is being done now, there is a bunch of extra code
involved, continually checking wether rc and errno agree. If errno != 0 but
rc == true, an error is reported and ignored, as rc is believed to _always_
be right, as (like you said) errno does not necessarilly have to remain 0
all of the time. The reason I reported this, is because I thought it weird
that errno should be nonzero after a call to time, which should, as far as
I know, only take a look at a certain memory block in my computer, where
the time is stored & updated every 18.2 parts of a second (the system
timer).
In short, this is not a bug in my program, it's by design (an undocumented
feature, so to speak ;->) but will be removed after debugging, as it only
slows down the program once all bugs are gone (if ever).

Greetz!

Dlanor

-----
This message reached you from the messy desktop of:
  Ronald Landheer
  <dlanor AT dds DOT nl>
Currently working his butt off at:
  The University of Amsterdam
  Faculty of Biology
  Kruislaan 318
  1098-SM Amsterdam
  The Netherlands