PE>
  > E.g. how many people don't see 3 things in
  > the following program that make it non-ISO?
  >
  > // Print hello world!
  >
  > void main(int argc, char **argv, char **envp)
  > {
  >     printf("hello world\n");
  > }
PE>

  Three ?  I see at least five.

  ( Wrong return type for `main', POSIX 1003 extension for environment
    pointer, lack of a return statement in `main', lack of inclusion of
    the  header, and use of C++ comments in a C program. )

PE>
  > There is absolutely no requirement for realloc() to be implemented as
  > a call to malloc().
PE>

  Exactly.

PE>
  > MB> replacing malloc() and free() is not the kind of thing that the average
  > MB> programmer should be doing, it certainly should be properly supported.
  >
  > Not as far as ISO conformance is concerned.  ISO 7.1.3 says that if
  > you include a header file, then all the identifiers defined to be in
  > that header file become reserved.
PE>

  Spot on.

PE>
  > MB> There a lot of these little problems in the Borland library, most of th
  > MB> rather innocuous until they get you.  Another unreplaceable function is
  >
  > None of the points you have mentioned detract in any way from Borland's
  > conformance with the ISO C standard.
PE>

  We agree again.

  Although there are problems with Borland's implementation, Mike did
  not identify them.

PE>
  > That is NOT what it means.  What it means is that, for example, if
  > tmpnam() is implemented by use of an internal static buffer, and a
  > pointer to that buffer is returned to the caller, then the caller
  > can expect that pointer to point to the same bit of data with the
  > same contents until the CALLER decides to call tmpnam() again.  If
  > another function, e.g. strcpy() had a need for a function exactly
  > like tmpnam(), the implementor of strcpy() is NOT allowed to touch
  > that static buffer.
PE>

  I took a slightly different tack, in that another part of the same
  guarantee is that no internal temporary filename generation can
  detract from the number of unique filenames guaranteed to you by
  TMP_MAX.  But we still agree on the basics.

PE>
  > MB> creatively to mean that replacing the function leaves the other library
  > MB> functions calling the original version.
  >
  > All of which Borland is perfectly entitled to do, and claim 100%
  > ISO conformance.
PE>

  Yes.

PE>
  > However I do know that if you think that this has ANY bearing
  > whatsoever in Borland's level of compliance to the ISO standard, you
  > have to demonstrate it in relation to the ISO C standard, not just
  > pick out library code that you don't think is well-written.
PE>

  On the other hand, there are certain parts of the Borland Standard C
  Library implementation where you can see that badly written code has
  introduced non-conformances.

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.00