Jonathan de Boyne Pollard wrote in a message to Mike Bilow:

 JdBP>   There is *no* requirement in Standard C that calling
 JdBP> realloc() causes   implicit references to malloc() and
 JdBP> free(), either.  The granularity   of the library may be as
 JdBP> fine as desired, even down to the level of   individual
 JdBP> library functions being single units.

I think we are at something of a misunderstanding.  I would concede that
Borland would be within its rights to have the link fail outright if a
library function is replaced, but the issue is what happens when the link
succeeds.  In effect, ANSI C does guarantee that replacing a library
function should prevent the superseded library function from being called. 
What happens in the Borland library is that realloc() continues to call the
original malloc() if malloc() is replaced, and that seems to be a problem. 
Even if it would be conforming behavior to have realloc() fail outright in
this cases, the actual behavior is. I think, non-conforming.

MB>
  >                                       Another unreplaceable
  > function is tmpnam(), since the original function will
  > still be secretly called by fclose() for a file created
  > with tmpfile().  The ANSI C standard specifies in this case
  > that tmpnam() shall behave as if no other library function
  > calls it, meaning that it can be replaced, [...]
MB>

 JdBP>   Again, this is incorrect.  The meaning of that particular
 JdBP> sentence is   that the number of unique filenames guaranteed
 JdBP> available via tmpnam(),   and the contents of the buffer
 JdBP> returned from the function, are   unaffected by any secret
 JdBP> use of temporary files by the remainder of   the Standard C
 JdBP> Library.

 JdBP>   In other words, that sentence *requires* that there be a
 JdBP> secret   internal function for generating temporary
 JdBP> filenames if any of the   remainder of the library needs to
 JdBP> generate temporary files. 

I don't agree with your reading of that sentence.  In any case, the Borland
implementation is certainly non-conforming, because the number of uniques
filenames is, in fact, reduced by the hidden calls into tmpnam().  I would
have to look again to see if the static buffer is affected, but I think it
is.

MB>
  > I have gone around with the Borland C library enough times to know
  > that is has serious problems for any but the most unambitious
  > programmer.
MB>

 JdBP>   I've completely rewritten the Borland C/C++ standard
 JdBP> library, and I   agree with your sentiments.  I just
 JdBP> disagree with the specifics, since   you are picking on the
 JdBP> parts where Borland is actually conforming to   the
 JdBP> standard.

I agree with you about the malloc() issue in some ways, but I assert that
there is some range of acceptable behavior when replacing a library
function, and I think Borland goes outside of that range.  The tmpnam()
issue seems to me to be a clearer case.

 JdBP>   I'd say that the main annoyances with the Borland
 JdBP> implementation of   the Standard C Library are

 JdBP>      X the pollution of the standard headers with
 JdBP> non-standard verbiage, 

This goes without saying.

 JdBP>      X the poor POSIX 1003.1 implementation (there's no
 JdBP> , and        many POSIX functions are missing),

This is true, and it could have been handled in a way that would not
interfere with ANSI C compliance.  Currently, you have to disable POSIX
completely to get ANSI compliance.

 JdBP>      X the poor granularity of the library (the Standard C
 JdBP> I/O functions        pull in a whole load of POSIX I/O
 JdBP> functions, for example), 

This is mostly part of the MS-DOS heritage of the Borland compiler and
library.  Since MS-DOS really follows the POSIX model internally, it is a
natural implementation to write the stream functions to call the POSIX
functions.  This does lead to problems.

 JdBP>      X failure to implement extensions for file sharing in
 JdBP> the obvious        manner (fopen() allows
 JdBP> implementation-specific characters after        the first
 JdBP> three "mode" characters, and that is the logical place      
 JdBP>  to add file sharing controls),

I thought that was fixed, but I haven't used Borland in a while for new code.

 JdBP>      X the lack of internationalisation support (strftime
 JdBP> could at least        query OS/2 for whether the machine
 JdBP> uses the Japanese, U.S., or        European date format),
 JdBP> and

I would be happy if they could just fix the time zone conversions.

 JdBP>      X the stupid legacy DOS code with the stupid legacy DOS
 JdBP> limitations        (e.g. 8.3 filename limitations) still
 JdBP> hard-coded in.

That's one of the first things I noticed was done correctly in Watcom.

MB>
  >              I think the last straw was when I looked in
  > the Borland library source and found a value being set to -1U.
  > Is that (unsigned)(-1)?  Or is it (unsigned long)(-1)?
  > Or is it both at once?
MB>

 JdBP>   -1U is (unsigned int)(-1), due to the standard promotion
 JdBP> from (signed   int) to (unsigned int).  If you want the long
 JdBP> int version, use -1UL. 

 JdBP>   The conversion from signed to unsigned is defined to use
 JdBP> modulo 2^N   arithmetic, incidentally, so -1U has a definite
 JdBP> value.

 JdBP>   It's actually quite a convenient idiom.

I mistyped that; it should have been "-1UL" -- as is obvious.  As
I understand ANSI C, the construct "(unsigned long)(-1)" is a
meaningful and well-defined "convenient idiom," as you put it. 
However, 6.1.3.2 defines an integer constant such that the sign is not a
part of the constant; the sign is a unary operator applied to the constant.
 Therefore, "-1UL" should not be parsed as "(-1)UL" but
rather as "-(1UL)."  The unary minus operator causes the value
"1UL" to be converted to "1L" -- a signed long -- per
6.2.1.2, so the result of the unary minus operator is itself of type signed
long.  All I am saying is that there is a substantial difference between

   (unsigned long)(-1)

   -((signed long)(1))

In my opinion, using constructs such as "-1UL" in a library, of
all places, is not a good idea.
 
-- Mike


---