clp@altos86.UUCP (Chuck L. Peterson) (05/20/89)
The library calls setpgrp and getpgrp both use the setpgrp() system call. Setgrp() gets translated to setgrp(1), and getpgrp gets translated to setpgrp(0). The manuals are consistent with the library call and say that setpgrp takes no argument. Are there any other cases where the C library changes arguments to system calls? This seems odd. Chuck L. Peterson ...!sun!altos86!clp
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/21/89)
In article <1127@altos86.UUCP> clp@altos86.UUCP (Chuck L. Peterson) writes: >The library calls setpgrp and getpgrp both use the setpgrp() system call. >Setgrp() gets translated to setgrp(1), and getpgrp gets translated to >setpgrp(0). The manuals are consistent with the library call and >say that setpgrp takes no argument. Are there any other cases where >the C library changes arguments to system calls? This seems odd. Perhaps the kernel implementors were trying to keep the GATE switch array as small as possible. So long as the C library interfaces to the system calls function properly, what do you care how they're implemented?
allbery@ncoast.ORG (Brandon S. Allbery) (05/26/89)
As quoted from <1127@altos86.UUCP> by clp@altos86.UUCP (Chuck L. Peterson): +--------------- | The library calls setpgrp and getpgrp both use the setpgrp() system call. | Setgrp() gets translated to setgrp(1), and getpgrp gets translated to | setpgrp(0). The manuals are consistent with the library call and | say that setpgrp takes no argument. Are there any other cases where | the C library changes arguments to system calls? This seems odd. +--------------- Historically, yes. Consider that system calls are designed to be called at the level of assembler, not C. An example (this may or may not be true any more, but I'm betting that it is): fork() used to be (still is?) used in the following way: movl %d0,#SC_FORK ; number for fork syscall trap ; trap to kernel jmp parent ; I may have these two swapped jmp child That is, the newly created process starts executing one "JMP" instruction away from the original process. Weird. Some systems treat u-area get/set functions as aspects of a single system call. I don't know if any of the major Unixes do this. (Example: getpid() becomes getset(GS_GET, GS_PID, 0).) The signal() system call linkage in C is sometimes (always?) a wrapper for the *real* signal syscall; the kernel doesn't build a C stack frame when it traps the signal, so signal() saves the C function address in an array and sets the signal trap for an internal routine (in assembler) which builds a C stack frame and then calls the C trap routine, then breaks down the stack frame and does a "return from interrupt". (I discovered this after the n'th time that a program wouldn't link because "_sigtrap" was multiply defined under Plexus System III.) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser