G'Day Paul,
 
-=> Quoting Paul Edwards to Frank Adam <=-

 PE> strcmp() is not a function that answers that question.  strcmp() is
 PE> a function which answers the question "which one of these strings
 PE> is 'alphabetically' bigger".
Hmmmm, you wouldn't be just pulling my leg here ? :)
The draft or any manual i have won't really expand on it any further 
than, "compares two strings" or BC's "signed comparison of
strings".
I would've thought that the prime objective would be to find out if they 
are equal.  
 
 FA> rename(this,that); if(OK) bla;
 FA> And in that one i'd rarely care about anything but a success.
 PE> Ok, this function returns 0 on success, non zero (not necessarily 1),
 PE> on failure.  Functions are often implemented like this so that if
 PE> nothing went wrong, you get a 0, but if something went wrong, you 
 PE> can have 27 million different return codes, all telling you what
 PE> went wrong.
Yes, but in system and disk operations at least, usable return codes are 
not returned by the function, but placed into errno instead.
 
 PE> Actually that returns a pointer, which is a far cry from a boolean
Hmm, let's see a show of hands, who never tested a pointer for FALSE.
 
 FA> It was still more interesting than the 'goto' thread in C_ECHO, and 
 FA> nobody
 FA> flew off the handle here :-) 
Not yet anyway.. :-)
                    
 PE> No-one in here is ever on the handle in the first place.  We're all
That may explain it :) 

 PE> ISO-C bigots.  Well we should be, anyway.  :-)  BFN.  Paul.
Due to you "bigots" i'm getting there too. :)  Having browsed through the 
draft, a few things make more sense now, but still a few 
"why on earth have it this way" questions come up now and then. 

  L8r Frank (fadam{at}ozemail.com.au).
  
___ Blue Wave/DOS v2.21

--- Maximus 3.01