Kelly Schrock wrote in a message to Mike Bilow:

 > Another thing to watch out for in Borland is that replacing
 > individual  functions of the run-time library will sometimes fail 
 > because of ANSI violations.  For example, replacing  tmpnam() will
 > fail because the original version of tmpnam()  calls a private
 > (pascal) function __MKNAME(), and fclose()  calls __MKNAME() directly
 > rather than properly calling  tmpnam().  As a result, file created
 > with tmpfile() are  created using your replacement tmpnam(), but are
 > never  deleted because fclose() gets the wrong name.  I consider  that
 > a bug, while Borland considers it an optimization.  Of  course, you
 > can try to replace __MKNAME(), but its calling  parameters change
 > with different versions of the compiler,  and its pascal calling
 > convention causes that to have  catastrophic effects on the stack...

 KS> Eeew. Glad there's no code in this library that opens files,
 KS> etc. For that, i'm using mainly iostreams. I just hope
 KS> Borland hasn't messed that up, too.

I could tell worse horror stories about what happens when you try to
replace malloc() and free() in the Borland library.  Even the stack goes
unstable.
 
-- Mike


---