ML> standard, non-ANSI library functions have an underscore as the leading
ML> symbol in the function name.

PE> There is no requirement for this, unless they interfere with
PE> the namespace of the resultant executable.  You will find
PE> that with a compiler such as Borland, which has a kbhit(),
PE> you can create your own function called kbhit(), and it will
PE> not clash with the one that Borland provide.  You are free
PE> to be blissfully unaware that they provide such a function
PE> as an extension, and so long as YOU follow the ISO standard,
PE> your program will compile, link and run properly.

MB> It is bad practice, in my opinion, for a compiler vendor to supply 
MB> functions with names which make it hard to distinguish non-portable 
MB> functions from portable functions.  

It's not really any worse than all the posix functions not starting
with an underscore, or all the Xwindows, MS-Windows, OS/2 PM etc etc
calls not starting with an underscore.  I don't think Borland should
be precluded from creating add-in functions just like EVERYONE else
does, just because they happen to be selling a compiler!  :-)

MB> Many Borland C programmers get tripped 
MB> up when they try to use a standard compiler, because they are duped into 
MB> thinking that functions such as outtext() are parts of the C language like 
MB> printf().

That's where the phrase "Borland Fan" comes from, and is entirely
the fault of the people passing themselves off as C programmers
when they usually don't even know how to write a "hello, world"
program in the *C* language (as opposed to a superset provided by
a particular vendor).  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");
}

Answer: heaps!

MB> In addition, you can get into very bad trouble with Borland C by replacing 
MB> library functions, since many of them call each other.  If you decide, for 
MB> example, to replace malloc() and free(), then you will find that realloc() 
MB> still calls into the original malloc() rather than your new one.  While 

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

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.

MB> There a lot of these little problems in the Borland library, most of them 
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.

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

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.

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.

MB> I have gone around with the Borland C library enough times to know that it 
MB> has serious problems for any but the most unambitious programmer.  I think 
MB> the last straw was when I looked in the Borland library source and found a 

As someone programming in ISO C, you are only allowed to refer to the
ISO/IEC 9899:1990 if you want to claim a compiler is not conforming,
not to the source code itself.

MB> value being set to -1U.  Is that (unsigned)(-1)?  Or is it (unsigned 
MB> long)(-1)?  Or is it both at once?

Why would you think it would be (unsigned long)?  What reason would
the compiler have to promote it to that?  But to answer your question,
I don't actually know what the Borland compiler will do for that.
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.

BTW, I do know of a Borland non-conformance, unless I am missing
something...

The following function prints "37" and "32" under
Borland C++ 1.5.
I would report it to Borland, but they have a habit of not answering
my questions, or I have to argue the toss over it with Australian
staff who have a flimsy knowledge of the C language because they're
not developers, but who feel a need to earn their money by fobbing
people off here instead of pestering the developers, and whenever
Borland do acknowledge a bug, they fix it by providing a $200
upgrade to the next version, with another raft of bugs.  For this
reason, I think GNU/EMX 0.9a patch 3 with the -Zomf -Zsys options
is one of the better C environments available.

BTW, if someone wants to defend Borland on this program, I don't
want any lame excuses about things that aren't defined by ISO,
e.g. stdprn.  If you want to claim ANSI/ISO conformance, then
dammit, you must conform.


/* Test maximum number of files that can be opened */
/* Written by Paul Edwards and released to the public domain */

#include 

int main(void)
{
    int x;
    char fnm[FILENAME_MAX];
    FILE *fq;

    printf("ISO guarantees at least %d\n", FOPEN_MAX - 3);    
    for (x=0; x< 200; x++)
    {
        sprintf(fnm, "maxxx.%d", x);
        fq = fopen(fnm, "w");
        if (fq == NULL)
        {
            printf("max is %d\n", x-1);
            return (0);
        }
    }
    printf("max is at least %d\n", x);
    return (0);
}
@EOT:

---