Using Symbolics C with DOS/Unix targets

[rwk@crl.dec.com (Robert W. Kerns)]

    Date: Sun, 17 Nov 1991 04:59 EST
    From: barmar@think.com (Barry Margolin)

       Date: Thu, 14 Nov 1991 14:38-0600
       From: gooch@TIJERAS.SW-SW.Dialnet.Symbolics.COM (William D. Gooch)

       Has anyone thought about using (or better yet, used) Symbolics C to hack
       existing programs for portability?  I'm thinking of an arrangement along
       the lines of CLOE, where the Symbolics machine is the network master for
       development and debugging, and combat-ready code is spat toward target
       machines using IP/TCP.  Final testing, possibly tuning, etc. happens on
       the target system.  You could even think of producing system .make files
       and so forth automatically when appropriate, also per CLOE.  (Come to
       think of it, it's quite possible that the CLOE Developer could be
       adapted for this purpose fairly easily.)

    The most significant problem with using Symbolics C to develop programs
    intended for Unix or DOS is the limited C library available in Genera.
    Many Unix and DOS programs make use of Unix system calls (most of the file
    system interface functions are emulated on DOS, but not Genera),
    screen-handling libraries (e.g. curses), networking interfaces (e.g.
    sockets), databases (e.g. dbm), etc.  Symbolics C provides nothing but the
    ANSI C library.

It's also not clear how much advantage it has over such things
as Saber C (recently renamed due to company name conflict to
something boring that I can't remember), or even Lightspeed C
These are very graphicly-oriented incremental, dynamic C environments
with such things as unbound-variable detection, etc. that give
you most, if not all, of the advantages of Symbolics C.

Also, developing portable C code is harder than you think.  It's
not just a matter of having a strict ANSI compiler.  You have to
contend with non-ANSI compilers, compilers with bugs, compilers
with a whole slew of ANSI-sanctioned variations (like the length
of 'int').  Adding one more compiler to this mix is likely to
cause you more problems than it solves.

The problem gets exponentially worse when you have to deal with
the variations in libraries that Barry mentions.  We have it
good in the Lisp world, portability wise.