Path: utzoo!utgpu!attcan!uunet!vsi!friedl From: friedl@vsi.COM (Stephen J. Friedl) Newsgroups: comp.sys.att Subject: Re: mkdir missing from libc.a Summary: careful with syscall() Message-ID: <1165@vsi.COM> Date: 12 Aug 89 03:04:31 GMT References: <475@mccc.UUCP> <1160@vsi.COM> <8057@mtune.ATT.COM> Distribution: na Organization: V-Systems, Inc. -- Santa Ana, CA Lines: 26 [ discussion on how to get access to SVR3 system calls with an ] [ old compiler without the latest SVR3 libc.a. ] In article <8057@mtune.ATT.COM>, jrw@mtune.ATT.COM (Jim Webb) writes: > If you don't want to trade up to the CPLU4.2 compiler (which *is* > fantastic, I might add, too) you can access any system call via > the syscall() routine. One must be careful with syscall(). Most system calls (open, read, etc.) are just little wrapper functions in C that set up the parameters for the GATE assembly instruction, and syscall() is just a general-purpose interface for it. Not all system calls, however, are this simple, and you can't simply vector into the operating system this way. I don't have any kind of comprehensive list, but I believe that the entire signal() family -- one of the improvements with SVR3 -- has significant extra code that you don't get with syscall(). Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / {attmail uunet}!vsi!{bang!}friedl / friedl@vsi.com "My new bestseller, _Teach_Yourself_to_Read_, is now available everywhere" -me