tony@oha.UUCP (Tony Olekshy) (03/30/89)
In article <301@oha.UUCP> tony@oha.UUCP (me) wrote: >And from the SVID (quasi-portable, if you have SV or Xenix or ?): ... > if (nlist(*argv, nameinfo) == -1) { and in article <1989Mar29.204918.3882@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) wrote: > > The problem here is the assumption that argv[0] is a full pathname for > the program. In general it's not, and finding the binary is not a > trivial exercise. Henry is, of course, completely correct, so two things are possible: a) Hand code the name to address mapping as a structure array, which is what I do with production code. This was already mentioned by the poster of the original question, who was asking for other ways. b) Deliberately make the name of the binary known during the installation process, and check the consistency of this information at run-time. This is an alternative which meets the needs set out in the original posting. Perhaps this is one for a future addition to C? I'd suggest a syntax, but the snow is already melting here without any help from the net ;-) Yours, etc., Tony Olekshy (...!alberta!oha!tony or tony@oha.UUCP).
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/31/89)
In article <302@oha.UUCP> tony@oha.UUCP (Tony Olekshy) writes: > b) Deliberately make the name of the binary known during the installation > process, and check the consistency of this information at run-time. > This is an alternative which meets the needs set out in the original > posting. It's unworkable, especially in a true networked environment, but even in traditional UNIX environments where an executable binary need not be readable to its invoker. (So you still can't read the name list.) Also, a stripped executable may not have a name list.
friedl@vsi.COM (Stephen J. Friedl) (03/31/89)
Henry Spencer wrote: > > The problem here is the assumption that argv[0] is a full pathname for > the program. In general it's not, and finding the binary is not a > trivial exercise. In article <302@oha.UUCP>, tony@oha.UUCP (Tony Olekshy) writes: > Henry is, of course, completely correct, so two things are possible: > > b) Deliberately make the name of the binary known during the installation > process, and check the consistency of this information at run-time. > This is an alternative which meets the needs set out in the original > posting. First, ksh provides the full pathname in $_, but this of course can be fooled. When Sys V Rel 4 comes out, you'll be able to get a file descriptor to your own executable with an ioctl on a /proc/##### file, where ##### is your pid. If there is a symbol table there you will be able to reliably map a function name to an address at runtime. /proc is really cool. Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl "I do everything in software, even DMA" - Gary W. Keefe (garyk@telxon)
arnold@mathcs.emory.edu (Arnold D. Robbins {EUCC}) (04/01/89)
This thread started with a question about mapping names in strings to function addresses. In article <1079@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >When Sys V Rel 4 comes out, you'll be able to get a file descriptor >to your own executable with an ioctl on a /proc/##### file, where >##### is your pid. If there is a symbol table there you will be able >to reliably map a function name to an address at runtime. > >/proc is really cool. Agreed, /proc is cool. Unfortunately, nlist(3) takes a path name, and not a file descriptor. There is a way around it, but what I want to know is if it will be in SVR4. I have in mind using /dev/fd, like so: sprintf (myproc, "/proc/%05d", getpid()); myprocfd = open (myproc, O_RDONLY); myimage = ioctl (myprocfd, PROC_GETIMAGEFD /* or whatever */, 0); sprintf (imagename, "/dev/fd/%d", myimage); nlist (imagename, nl); .... or will there be a new version of nlist? -- Unix is a Registered | Arnold Robbins -- Emory University Computing Center Bell of AT&T Trademark | DOMAIN: arnold@unix.cc.emory.edu Laboratories. | UUCP: gatech!emory!arnold PHONE: +1 404 727-7636 -- Donn Seeley | BITNET: arnold@emoryu1 FAX: +1 404 727-2599