Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!rutgers!mtune!codas!usfvax2!chips
From: chips@usfvax2.UUCP (Chip Salzenberg)
Newsgroups: comp.lang.c
Subject: Re: What real non-UNIX 'C' compilers implement...
Message-ID: <834@usfvax2.UUCP>
Date: Sun, 13-Sep-87 18:06:42 EDT
Article-I.D.: usfvax2.834
Posted: Sun Sep 13 18:06:42 1987
Date-Received: Tue, 15-Sep-87 04:30:41 EDT
References: <672@sugar.UUCP> <3545@venera.isi.edu>
Organization: AT Engineering, Tampa, FL
Lines: 25
Summary: Turbo C's manual needs...

In article <3545@venera.isi.edu>, lmiller@venera.isi.edu (Larry Miller) writes:
}
} The problem goes beyond just read and write, to any OS system calls.  The
} new Turbo C makes things worse because, unlike UNIX which separates system
} calls (Section 2 in the manual) from C library routines (Section 3), Turbo
} C just gloms them all in alphabetical order in the reference manual.  NO
} new programmer to C would have any inclination that some calls are portable
} C, and some are DOS specific.
} 
} A good reorganiztion of the Turbo C reference manual is in order.
} 
} --
} Larry Miller

The one thing I like about Lattice is that their C manual tags functions with
a `type' -- ANSI, UNIX, XENIX, MS-DOS, etc.  Thus you can pick the function(s)
that are available on the range of systems important to you.  (Why restrict
yourself to ANSI function calls for a throw-away utility?)

I like Turbo's reference manual.  I usually use it even when programming on
Xenix. (Of course, Turbo doesn't have msgctl(), but I can read the SVID. :-))
-- 
Chip Salzenberg            UUCP: "uunet!ateng!chip"  or  "chips@usfvax2.UUCP"
A.T. Engineering, Tampa    Fidonet: 137/42    CIS: 73717,366
"Use the Source, Luke!"    My opinions do not necessarily agree with anything.