Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: syscall(2) function (really: syscall(3))
Message-ID: <9820@smoke.BRL.MIL>
Date: 8 Mar 89 03:26:32 GMT
References: <3740@ucdavis.ucdavis.edu> <8984@alice.UUCP> <9757@smoke.BRL.MIL> <1449@ubu.warwick.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <1449@ubu.warwick.UUCP> mirk@uk.ac.warwick.cs (Mike Taylor) writes:
>Ask yourself how *that* ties in with this apalling move?

IT HAS NOTHING TO DO WITH IT.

It's also not an "appalling move".  In fact it is designed to make it
possible to port C applications around between widely different types
of operating systems, something that is problematic if each system's
C environment be allowed to preempt names from the application for its
own use.

In a UNIX implementation of C, I would expect that you could still get
at the open() system call by that name.  However, the portable C library
must not use that name if it could accidentally be linked so that an
application-provided function named open() would be used where a system
call interface is expected by the library implementation.  Thus the need
for the library to be implemented using calls to names outside the
application's name space, e.g. __open().