PE> SS>> Is CSet++ 100% ANSI C compatible?  I'm careful to use
ANSI C functions
PE> SS>> as

PE> PF> Yes,  even more so than Borland in my experience.  I too am mainly a C
PE> PF> programmer.

PE>Please name the things that Borland isn't 100% ANSI C compatible in.  I only

I may be wrong here (not unusual) but I believe that ANSI recommends
that non-ANSI standard-library routines names should start with an
underscore.

CSet++ supports this by using the following names for common (but not
ANSI) functions:

        BORLAND          ANSI recommendation (IBM CSet++)

        open                        _open
        close                       _close
        read                        _read
        write                       _write

There are more, these are just a few examples.

Now this is not *manditory* under the ANSI standard but it is
recommended so I guess that's why IBM's CSet++ has used the recommended
naming techniques.  Borland (and MS) have chosen to use the older (still
valid for POSIX libraries) naming convention.

I see that MS uses this recommendation for its _dos* functions but uses
the older (open,close) naming for other non-ANSI std-library functions.

This means of course that even if your code is 100% ANSI compliant it
may still fail to compile without change on another machine if you've
used non-ANSI library functions and ANSI doesn't seem to provide much in
the way of support for shared-file operations which are becoming so
commonplace in multi-tasking/multi-user environments.

Note: Watcom's (ANSI compliant) compiler also uses the POSIX conformant
naming conventions but I *always* use a header file which #define's the
POSIX names to the ANSI recommended form, eg:

#define  _open  open
#define  _close close

That way my code conforms to both the ANSI standard *and* the ANSI
recommendations.

--- Enigmax v1.04a