gwyn@smoke.brl.mil (Doug Gwyn) (01/24/91)
In article <mpapp.664709840@godzilla> mpapp@ (Mike Papper) writes: >Can I find the adress of a function from its name? No, there is no universal method for that, at least not without the code having be deliberately set up to contain a table of function-name strings and associated function pointers. Any system-specific method we might give you amounts to "use a debugger".
mike (Michael Stefanik) (01/24/91)
In article <mpapp.664709840@godzilla> !mpapp (Mike Papper) writes: |Again, the question, a bit more succintely is: |Can I find the adress of a function from its name? |That is, given the text string of a function, can I |get its adress to give to a pointer variable? This is a solution only if your using UNIX ... There is a function called nlist() that will read the namelist of an image, and return various and sundry tidbits of information. One of these tidbits is n_value, which is the value of the symbol. Might be helpful. -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
mpapp@ (Mike Papper) (01/24/91)
Sorry to post this again, but all the replies I got were expired by
the time I read them.
Again, the question, a bit more succintely is:
Can I find the adress of a function from its name?
That is, given the text string of a function, can I
get its adress to give to a pointer variable?
I have looked a bit at ldfcp and related but
find it a bit too much to look at at once,
does someone else already know what to do?
Mike Papper
mpapp@godzilla.cgl.rmit.oz.au
--
----------------------------------------------------------------------------
Greg Farrelly, Computer Centre,
Applications Programmer. Royal Melbourne Institute of Technology,
P.O. Box 2476V, Melbourne. 3001. bengsig@dk.oracle.com (Bjorn Engsig) (01/24/91)
Article <mpapp.664709840@godzilla> by mpapp@ (Mike Papper) says:
|Can I find the adress of a function from its name?
If this is a pure C question, the answer is that you have to create a symbol
table of the functions you need to lookup and search for them yourselves.
If this is a question to C on (certain) Unix implementations, then you could
try starting with the manual page for ldopen. It will point you to a family
of routines that cope with object files, symbol tables etc. but I guess it
is not really what you want.
--
Bjorn Engsig, ORACLE Corporation, E-mail: bengsig@oracle.com, bengsig@oracle.nl
"Stepping in others footsteps, doesn't bring you ahead"gwyn@smoke.brl.mil (Doug Gwyn) (01/26/91)
In article <388@bria> bria!mike (Michael Stefanik) writes: >There is a function called nlist() that will read the namelist ... There are several problems with nlist(), apart from UNIX dependence. One is that you have to tell it a path to the executable file, and that is not in general available for the currently-executing process. Another is that often the symbol table is stripped off the executable file in order to conserve disk space.
sarima@tdatirv.UUCP (Stanley Friesen) (01/26/91)
In article <mpapp.664709840@godzilla> mpapp@ (Mike Papper) writes: >Again, the question, a bit more succintely is: >Can I find the adress of a function from its name? Not in any simple or portable way. Most flavors of Unix provide some set of library routines for accessing symbol tables in binaries. However, there is no standard set, the library changes completely from SysVr3 to SysVr4! Given such a library, and an *unstripped* executable, it is possible, with much contortion, to convert a function name into an address. Essentially you need to locate the binary being executed (not always easy), and 'open' it in the way prescribed by the library, and then grub around in the symbol table using the mechanism(s) provided. -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
wolfram@ikki.informatik.rwth-aachen.de (Wolfram Roesler) (02/08/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >One is that you have to tell it a path to the executable file, and >that is not in general available for the currently-executing process. Sure? How about argv[0] ?
henry@zoo.toronto.edu (Henry Spencer) (02/09/91)
In article <wolfram.666028267@ikki> wolfram@ikki.informatik.rwth-aachen.de (Wolfram Roesler) writes: >>One is that you have to tell it a path to the executable file, and >>that is not in general available for the currently-executing process. > >Sure? How about argv[0] ? argv[0] usually, but not always, contains the name under which the program was invoked. That has no guaranteed relationship to its pathname. -- "Maybe we should tell the truth?" | Henry Spencer at U of Toronto Zoology "Surely we aren't that desperate yet." | henry@zoo.toronto.edu utzoo!henry
kym@bingvaxu.cc.binghamton.edu (R. Kym Horsell) (02/09/91)
In article <wolfram.666028267@ikki> wolfram@ikki.informatik.rwth-aachen.de (Wolfram Roesler) writes: >gwyn@smoke.brl.mil (Doug Gwyn) writes: > >>One is that you have to tell it a path to the executable file, and >>that is not in general available for the currently-executing process. > >Sure? How about argv[0] ? Sure! What about execXXX -- it's only a _convention_ that argv[0] is installed as any kind of filename. -kym
gwyn@smoke.brl.mil (Doug Gwyn) (02/09/91)
In article <wolfram.666028267@ikki> wolfram@ikki.informatik.rwth-aachen.de (Wolfram Roesler) writes: -gwyn@smoke.brl.mil (Doug Gwyn) writes: ->One is that you have to tell it a path to the executable file, and ->that is not in general available for the currently-executing process. -Sure? How about argv[0] ? No, that is extremely unreliable.
steve@taumet.com (Stephen Clamage) (02/10/91)
wolfram@ikki.informatik.rwth-aachen.de (Wolfram Roesler) writes: >gwyn@smoke.brl.mil (Doug Gwyn) writes: >>One is that you have to tell it a path to the executable file, and >>that is not in general available for the currently-executing process. >Sure? How about argv[0] ? How about it? In an ANSI-conforming implementation (2.1.2.2.1): a. argc may be 0, and argv a null pointer. b. argv[0] may point to a null character. c. argv[0] may contain the program name with no path information. -- Steve Clamage, TauMetric Corp, steve@taumet.com
bhoughto@pima.intel.com (Blair P. Houghton) (02/11/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >One is that you have to tell it a path to the executable file, and >that is not in general available for the currently-executing process. wolfram@ikki.informatik.rwth-aachen.de (Wolfram Roesler) writes: >Sure? How about argv[0] ? In article <596@taumet.com> steve@taumet.com (Stephen Clamage) writes: >How about it? In an ANSI-conforming implementation (2.1.2.2.1): >a. argc may be 0, and argv a null pointer. >b. argv[0] may point to a null character. >c. argv[0] may contain the program name with no path information. d. argv[0] may contain grot. e.g., `execl("/bin/sh","my dog has fleas","-c","/bin/echo $0",0);' (using execl(3) under Ultrix). --Blair "my dog has fleas"
wolfram@akela.informatik.rwth-aachen.de (Wolfram Roesler) (02/13/91)
>gwyn@smoke.brl.mil (Doug Gwyn) writes: >>One is that you have to tell it a path to the executable file, and >>that is not in general available for the currently-executing process. >Sure? How about argv[0] ? Hello you pyromanics, stop flaming me for this line. I am sorry if I insulted a guru but if I want to contradict to anybody I do it regardless if he's a guru, the chinese emperor or anybody else. However, if the guru was seriously insulted by my comment I recommend psychotherapy. I did not say "argv[0] contains the executable path of the running prg". All I meant by my comment was that argv[0] can be used to obtain it. Not always, I know, not necessarily portably, I know too. I might be new to comp.lang.c but I am not new to C. And I hadnt yet read the FAQ (thanks for mailing me, whoever did). Using execl or some other syscall to make argv[0] be completely different from the bin path is very rarely used (calling login shells is the only example that comes to my mind). It's very easy to scan the $PATH and search for the executable file. This does not work always, I know. It will work most of the time, it will work always when a program is called in the regular fashion. So, (daring to contradict guru doug again,) it's not true that the executable path is not in general available to a process. It is available in general, since the general case is that a program is called with argv[0] containing at least a part of the executable path, and the rest can be obtained from $PATH. Once again, stop flaming me, you're wasting your time. And gurus, tell your disciples not to do so. And guru disciples, think if it's not a better thing to pray to Jesus of Jahwe or Buddha or anyone else.
gwyn@smoke.brl.mil (Doug Gwyn) (02/14/91)
In article <wolfram.666449950@akela>, wolfram@akela.informatik.rwth-aachen.de (Wolfram Roesler) writes: > >gwyn@smoke.brl.mil (Doug Gwyn) writes: > >>One is that you have to tell it a path to the executable file, and > >>that is not in general available for the currently-executing process. > >Sure? How about argv[0] ? > Hello you pyromanics, stop flaming me for this line. I am sorry if I > insulted a guru but if I want to contradict to anybody I do it regardless > if he's a guru, the chinese emperor or anybody else. However, if the guru > was seriously insulted by my comment I recommend psychotherapy. I was not insulted, nor did I flame you in response. However, you're still wrong about using argv[0] to obtain a path to the executable file. Very often even in a UNIX environment it will consist of only what is often termed the "simple" part of a pathname, i.e. what is left when all containing directory information has been stripped off. In other environments it can be even worse. I stand by what I said in my original note (quoted above). > Once again, stop flaming me, you're wasting your time. And gurus, tell > your disciples not to do so. And guru disciples, think if it's not a better > thing to pray to Jesus of Jahwe or Buddha or anyone else. If I have any "disciples", I would prefer to instruct them to not pray to anybody but rather learn how to acquire evidence and analyze the facts to determine what the truth actually is.
mike (02/14/91)
In an article, akela.informatik.rwth-aachen.de!wolfram (Wolfram Roesler) writes: |Using execl or some other syscall to make argv[0] be completely different |from the bin path is very rarely used (calling login shells is the only |example that comes to my mind). [...] Well, most programs that exec only hand the basename of the image to argv[0], although it would be a wonderful world if they provided the full path. Of course, it _is_ extremely poor taste to pass anything other than the image name in argv[0], but it is ocassionally done. Just can't depend on anything these days ... :-) -- Michael Stefanik | Opinions stated are not even my own. Systems Engineer, Briareus Corporation | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
garry@ceco.ceco.com (Garry Garrett) (02/23/91)
In article <8431@exodus.Eng.Sun.COM>, limes@ouroborous.Eng.Sun.COM (Greg Limes) writes: > In article <wolfram.666449950@akela>, wolfram@akela.informatik.rwth-aachen.de (Wolfram Roesler) writes: > |> >>One is that you have to tell it a path to the executable file, and > |> >>that is not in general available for the currently-executing process. > |> > |> >Sure? How about argv[0] ? > [...] > * > * PORTABILITY > * This was developed on a Sun3 running SunOS 4.0, but I think I > * at least made the algorithm portable. You may need to mess > * with include files and such. Symbolic link searching is turned > * on if your errno.h supplies ELOOP, and off otherwise; I assume > * that all systems with symlinks have a readlink() call. > * [...] Your solution is interesting, but I think that here is where you miss the point. C runs on many many many operating systems and platforms. I have no doubt that your code will run on a sun, or most unix systems. On the other hand, I doubt that it will run on a PC (MS-Dos), or a Mac or an Amiaga, or a prime, or a machine running the OS-9 operating system... The answer is, NO - there is no STANDARD way of knowing the name of the currently exicuting file. On many systems, argv[0] does contain the name of the currently exicuting file, often times with the full pathname. If your C compiler doesn't, send the author hate mail until the next version does, then maybe it will become a de-facto standard. In some cases, this is not possible because of the way that the operating system works. In otherwords, this information is not available from the operating system, so your compiler could not possible give you this information. If that's the case then you are stuck. :-(
scs@adam.mit.edu (Steve Summit) (02/24/91)
Various people write: >> |> >>One is that you have to tell it a path to the executable file, and >> |> >>that is not in general available for the currently-executing process. >> |> >Sure? How about argv[0] ? >> [semiportable code for making best guess at program's >> executable from argv[0] and $PATH] > Your solution is interesting, but I think that here is where you >miss the point. C runs on many many many operating systems and platforms. >I have no doubt that your code will run on a sun, or most unix systems. On >the other hand, I doubt that it will run on... > The answer is, NO - there is no STANDARD way of knowing the name of >the currently exicuting file. I think the person who posted the code realized that. I KNOW that this topic has been discussed to death countless times, and that all of these arguments have been brought up before, which is why they are summarized in the comp.lang.c frequently-asked questions list. Please read that list before posting anything else on this subject, and make sure that you have something new to say. Steve Summit scs@adam.mit.edu
limes@ouroborous.Eng.Sun.COM (Greg Limes) (02/25/91)
I have cancelled the article containing the source code for findx(). If you have not seen that article, or it did not disturb you, then just move on to the next article. Thanks. I would appreciate it if everyone who has decided to reply to me first read the FAQ, then read the block comment at the head of the code, then consider whether you actually have something constructive to say that has not been ground into the floor many times before now.
wolfram@cip-s05.informatik.rwth-aachen.de (Wolfram Roesler) (02/26/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >> However, if the guru >> was seriously insulted by my comment I recommend psychotherapy. >I was not insulted, nor did I flame you in response. No, you didnt, but somebody else did. He mentioned your name in a way that seemed really strange to me. He didnt really write "Shut up cause gurus are listened to but not contradicted" but this was what he problably intented to say. Remainded me of a Jehova's witness I once talked to, daring to say the bible is not a history book. Ok now, this has nothing to do with C anymore. Lets continue this in alt.politeness or alt.rules.how.to.treat.people.who.are.not.so.smart.as .you or alt.religion.zen.shoshin. >If I have any "disciples", I would prefer to instruct them to not pray >to anybody but rather learn how to acquire evidence and analyze the facts >to determine what the truth actually is. Quite right. BTW: Hi guru, how is the air up there? :-)