ZZ>
  > 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.
ZZ>

  Actually, realloc(void *,size_t) calls whatever malloc(size_t) you
  define.  Try compiling a test program with Borland C++.

  Nevertheless, there is nothing that says that realloc either should or
  should not be affected if you attempt to "knock out" malloc with your
  own function.  If you attempt to do so you are immediately in the
  treacherous waters of Undefined Behaviour.  Borland's implementation
  is as conformant as any other in this respect.

ZZ>
  > 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)."
ZZ>

  You were all right up to here.

ZZ>
  >                                             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.
ZZ>

  I don't have a copy of the ISO C Standard to hand here, but I do know
  that this is not the way that things work in the C++ Working Paper.

  In the WP, the result of applying the unary minus operator to an
  unsigned integral type is explicitly defined in terms of modulo 2^N
  arithmetic.  No conversion to a signed integral type occurs.  Only
  integral promotions apply, and they do not apply to `unsigned long
  int' anyway.  The result is thus also an unsigned long int.

ZZ>
  >                                                All I am
  > saying is that there is a substantial difference between
  >
  >    (unsigned long)(-1)
  >
  >    -((signed long)(1))
ZZ>

  There is a difference, in that the first is `signed int' with the
  unary minus operator applied (no promotion necessary), and then
  converted to unsigned long int (the result of which will vary
  according to the relative lengths of `int' and `long int'); and the
  second is `signed long int' with the unary minus operator applied (no
  promotion necessary).  The second should always yield -1L, and the
  first *may* yield -1L (and will on 32-bit OS/2 C++ compilers) but may
  not.

  However, neither of these are what you originally mentioned, which was
  `-1UL'.  This is 1UL with the unary minus operator applied (or, in
  terms of your above expansions `-(unsigned long)1').  No promotion is
  applicable, and the type is unsigned, therefore the definition in
  terms of 2^N arithmetic applies and the result is *always* 2^N - 1 .

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

  It's a well-formed construct, with a consistent and useful value.  As
  I said before, it is a convenient idiom.

  > JdeBP <
___
 X MegaMail 2.10 #0:

--- Maximus/2 3.00