Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!clyde!cbosgd!mandrill!hal!ncoast!allbery From: allbery@ncoast.UUCP (Brandon Allbery) Newsgroups: comp.unix.wizards Subject: Re: POSIX execlfd and execvfd proposal Message-ID: <6322@ncoast.UUCP> Date: Wed, 2-Dec-87 20:03:37 EST Article-I.D.: ncoast.6322 Posted: Wed Dec 2 20:03:37 1987 Date-Received: Mon, 7-Dec-87 06:47:57 EST References: <18491@linus.UUCP> <2470@tut.cis.ohio-state.edu> Reply-To: allbery@ncoast.UUCP (Brandon Allbery) Followup-To: comp.unix.wizards Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 31 As quoted from <2470@tut.cis.ohio-state.edu> by karl@tut.cis.ohio-state.edu (Karl Kleinpaste): +--------------- | ramsdell@linus.UUCP writes: | replacing the image, but after determining the identity of the file to | be exec'ed, they open the binary image and place the file descriptor in | an external int called "boot_fd". The exec fails if the open fails. | | consumption of yet another file descriptor. But more importantly, it | confuses the meaning of the permissions r-xr-xr-x and --x--x--x. What +--------------- Since the expressed intent is to be able to get at the namelist of the program, maybe a special system call should be created to return the process's namelist. I admit, it's ugly and non-Unix, but maybe this is itself an indication that, with dynamic loading being the latest development, the whole idea of the namelist should be re-evaluated. A possible solution is to distinguish between compiler symbols and "exported" dynamic-linking symbols; the latter would be stored as part of the process's "environment" (ublock). Another possibility is produced by System V shared libraries: system functions are always at a fixed address, "linkage" variables could also be placed at a fixed address, and a global table of linked-in functions would be used to call such routines. Of course, this makes dynamic functions not look like statically-linked ones, but I doubt that we could deal with that problem anyway (unless, of course, we all program in Lisp ;-). It also produces a difference in variables, which is an even more severe limitation. -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery Moderator of comp.sources.misc