🚀 go-pugleaf

In article <1990Sep1.170632.13330@cs.umn.edu>, martin@cs.umn.edu (Johnny Martin) writes:
> In article <3653@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> >SB Prolog itself doesn't need 'syscall' in its full generality.

> >If someone wants access to a particular system call that isn't numbered
> >in the SB Prolog manual, they can add their own case to the switch() that
> >I am proposing.  That's the advantage of having sources.

> In sbprolog, there is a limit on the number of builtins.

You weren't paying attention.  I was saying KEEP the SB-Prolog
predicate syscall and the C function that backs it up, BUT have it
go through a switch() that calls each of the necessary system calls
explicitly.  That is, eliminate calls to the ***C*** function syscall().
The number of builtins isn't relevant.  That doesn't need to change.

> but at least using syscall.h should make it a bit more portable.

No.  Some of the functions one wants to call may be syscalls() in some
flavours of UNIX (and thus be accessible through syscall()) but be
library functions in other flavours of UNIX (and thus not have syscall()
numbers assigned to them).  [alarm(), time(), and nice() spring to mind.]
In particular, note that DEC are said to be promising a POSIX-compliant
interface to VMS; syscall() is *not* part of IEEE 1003.1 at all (nor,
for that matter, is it in the SVID).
-- 
Heuer's Law:  Any feature is a bug unless it can be turned off.