Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!ritcv!moscom!jgp
From: jgp@moscom.UUCP
Newsgroups: comp.lang.c
Subject: Re: What real non-UNIX 'C' compilers implement...
Message-ID: <1059@moscom.UUCP>
Date: Tue, 29-Sep-87 20:03:17 EDT
Article-I.D.: moscom.1059
Posted: Tue Sep 29 20:03:17 1987
Date-Received: Fri, 2-Oct-87 04:17:50 EDT
References: <721@sugar.UUCP> <814@sugar.UUCP> <29156@sun.uucp>
Reply-To: jgp@moscom.UUCP (Jim Prescott)
Organization: MOSCOM Corp, E. Rochester, NY
Lines: 22

In article <29156@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
>Frankly, *I*'d like to see the distinction between section 2 and section 3
>erased completely, so that you don't know which library routines consist of a
>little glue and a "trap" call and which don't.

The Lattice C (V2) manuals clasified functions into levels instead of
indicating whether they were a system call or a library function.  Level 1
routines provided low level access with routines like sbrk() and read().
Level 2 and 3 functions provided higher level access with things like
malloc() and fread().

Things were sorted by function and subsorted by level number so that you
could see the alternative ways of doing something (eg. file I/O) grouped
together.  There was the logical concept that a level 2 function was just
an standard way of using a level 1 function.

Another problem with the labeling things as system calls is that a system
call on one system may be a library call on the next.  signal() is a system
call on most systems but on BSD 4.[23] it has been changed to a library call.
-- 
Jim Prescott	moscom!jgp@cs.rochester.edu
		{rutgers,ames,cmcl2}!rochester!moscom!jgp