I received a large code file, that I didn't write. There's a function being used in that code that I want to use myself in a separate code file. Is there a quick and simple way to find which of the (many) includes in the original code file makes this function available?
The fastest way is usually to grep for the function name (pro tip: use grep -rw to search recursively and for whole-word matches only). That assumes you have some idea which directories the header file may be in.
If that won't work, you can preprocess the file. With GCC that's the -E option instead of -c. This will output what the actual compiler sees, after #includes are resolved. Then you can easily search in the preprocessed file for the function declaration and look above that for which file it came from.
This completely depends on your developmnet environment. I often use ack tool (consider it as "better grep" for programmers) for that purpose, beside that I know that some IDEs have "go to definition" or "go to declaration" feature, so you can directly look for function's definition or its prototype.
Related
I'm trying to learn the use of header files in C. Now I found few resources in my research but none of them created the desired effect.
First, according to this tutorial, I can write my functions in the header file itself. But I don't want to do that. I want to keep the header file unchanged even if I changed the code given that the interface remains unchanged.
Answer to this question suggests two methods. First I can write the code and header file separately and include them when I compile as follows:
gcc -o myprog test.c library.c
But I don't want to do that either. My library functions should be readily available without needing to include in compile line. According to the same answer, I could create a library and then link to it with -l switch. But when it comes to functions like printf, you don't need to do either of them. All you have to do is to include the header files.Is there any way of doing that?
summary for TL;DR
I want to write a library in C which:
Doesn't have to be implemented in the header file itself.
Doesn't have to be included in the compile line every time I use the library functions.
Doesn't have to be linked with -l every time I use the library function.
Basically the library should be used by only including the header file.
Is there anyway that I could do it in Linux?
But when it comes to functions like printf, you don't need to do either of them. All you have to do is to include the header files.Is there any way of doing that?
Short answer is "no". Long answer is that C compiler links some libraries "for free", including the library that implements printf.
You have an option to decline these "freebies" - in gcc it's -nodefaultlibs. If you add this option, printf would be missing.
Note: One thing that headers can implement is macros. However, macros do not behave like normal functions, so you should approach them with great caution.
I wonder what is inside stdio.h and conio.h etc.
I want to know how printf and scanf are are defined.
Is there a way I can open stdio.h and see what is written inside?
Depending on your implementation, you should be able to open any .h file in your favorite editor and read it directly; they're (usually) just plain text files.
However, stdio.h will only give you the declarations for printf and scanf; it won't contain the source code for them. Most compilers don't ship the source code for standard library functions; instead, they ship precompiled libraries which are linked with your code when you build the executable.
If you're willing to spend some money, P.J Plauger's The Standard C Library is a good resource that shows an implementation of the standard library functions.
When the preprocessor includes a header file into a source file, that inclusion is very much literal. That means that the header files are normal text files with source in them, and must be readable by the compiler (and therefore by you). You just have to find where they are, and you can open them like any other text file.
However, you won't find out how functions are defined, just how they are declared. And some structures are supposed to be "black boxes", whose data members should be considered private. Usually the source for the standard C library is available or downloadable, so try and find that too. It all depends on what compiler you're using.
You might also want to check out a reference site such as this one. There you can find pretty detailed information about e.g. printf.
Those headers generally chain include more machine/OS specific headers.
If you are on Linux/OS X then you can get some more info with
man stdio
Also check out http://www.cplusplus.com/reference/cstdio/ https://en.wikipedia.org/wiki/Conio.h
Most compilers allow you to read the results after the preprocessor (the compilation step that processes the #include directives) has been run. With gcc for instance, use the -E command-line option.
You can always rely on the Internet's supply of Unix-style manual pages, by searching for "man something" you can look for the relevant manual section for something.
For instance, there are pages for both printf() and scanf().
You can easily see there that the declarations aren't very special, and quite obvious from the usage. It's just int printf(const char *format, ...); for instance.
the content of some headers is defined by the C-Standard.
other headers are defined by the library that provides it.
Some headers are defined from the system for that you are writing the code (may fall into the second case since the OS provides the libs)
depending on that you may look into c language reference or you may look into the libraries manual or in the OS's API reference.
But one thin is for sure. if you can include a header (and the compiler does not complain that he could not find it) than you also can look into it. just look into the standard include directories of the compiler or the additional include directories that are specified in project file ore Makefile to find the files on your file system.
But usually the better way is to look in the Documentation because the header itself may be difficult to read because of many #ifdefs and further includes
The most fundamental way to find out what's inside those headers is to read them. Of course, you must locate them first. To this end you can use this short shell code:
gcc -E -M - << EOF
#include <stdio.h>
EOF
This will provide you with a complete list of all the headers directly or indirectly included by #include <stdio.h>. Of course, if you are only interested in the 'stdio.h' header itself, you can just do
locate stdio.h
but this will usually list quite a few false positives.
From
How can I define a C function in one file, then call it from another?
Say I define a function in the file func1.c, and I want to call it from
the file call.c, how would I accomplish this?
and the answer
You would put a declaration for the function in the file func1.h, and add
#include "func1.h" in call.c. Then you would compile or link func1.c
and call.c together (details depend on which C system).
My question is does the name of the header file have to be func1.h, as in <name-of-c-file>.h, or is this just a best practice? Please provide link for reference if possible.
In c, you don't have to call your files anything at all. As such, you can call your header mylongheadername.h, while you call your source file a.c and have a function in it called justArandomFunctionName.
However, you should be aware that your source file needs to include your header file. Generally there is a strong link between headers and source files, so that's the reason this is just about always done in this way. However, the following is completely valid:
a.c : func1 implementation
func2 implementation
b.c : func3 implementation
func4 implementation
c.h : func1 declaration
func3 declaration
d.h : func2 declaration
func4 declaration
However, there are some problems to this approach that might occur when using files set up like this (which mean you have to put extra work into structuring these files right) and it's just poor practice. But, the way one uses header files is just convention and barely any of it is enforced by the language.
Then there is the question how this can work if the header file does not know where the function is defined. The idea of this is that it doesn't need to know.
Basically, all your header does is tell your compiler that somewhere you defined a function that fits a certain profile (what name, what parameters, what return type). When your compiler reads this, basically all it does is mix all this info into a fancy name, which it will then insert into the file that is calling, which means it still doesn't do anything. The next step you need to take is to use the linker to turn the compiled versions of each of your files into a single executable. This does a number of things, but one of the most important ones is that it resolves all those fancy names the compiler cooked up. However, the way that your linker does this, is that it just reads all the compiled versions of your files and matches the definition of functions to their actual location in other code. Because it just handles all you have at the same time, it doesn't matter where your functions were defined and the header file never needs to know this.
No, header files do not need to match any corresponding C source file. It is as you've said just convention.
What should I do if I have two libraries that provide functions with equivalent names?
It is possible to rename symbols in an object file using objcopy --redefine-sym old=new file (see man objcopy).
Then just call the functions using their new names and link with the new object file.
If you control one or both: edit one to change the name and recompile Or equivalently see Ben and unknown's answers which will work without access to the source code.
If you don't control either of them you can wrap one of them up. That is compile another (statically linked!) library that does nothing except re-export all the symbols of the original except the offending one, which is reached through a wrapper with an alternate name. What a hassle.
Added later: Since qeek says he's talking about dynamic libraries, the solutions suggested by Ferruccio and mouviciel are probably best. (I seem to live in long ago days when static linkage was the default. It colors my thinking.)
Apropos the comments: By "export" I mean to make visible to modules linking to the library---equivalent to the extern keyword at file scope. How this is controlled is OS and linker dependent. And it is something I always have to look up.
Under Windows, you could use LoadLibrary() to load one of those libraries into memory and then use GetProcAddress() to get the address of each function you need to call and call the functions through a function pointer.
e.g.
HMODULE lib = LoadLibrary("foo.dll");
void *p = GetProcAddress(lib, "bar");
// cast p to the approriate function pointer type (fp) and call it
(*fp)(arg1, arg2...);
FreeLibrary(lib);
would get the address of a function named bar in foo.dll and call it.
I know Unix systems support similar functionality, but I can't think of their names.
If you have .o files there, a good answer here: https://stackoverflow.com/a/6940389/4705766
Summary:
objcopy --prefix-symbols=pre_string test.o to rename the symbols in .o file
or
objcopy --redefine-sym old_str=new_str test.o to rename the specific symbol in .o file.
Here's a thought. Open one of the offending libraries in a hex editor and change all occurrences of the offending strings to something else. You should then be able to use the new names in all future calls.
UPDATE: I just did it on this end and it seems to work. Of course, I've not tested this thoroughly - it may be no more than a really good way to blow your leg off with a hexedit shotgun.
You should not use them together. If I remember correctly, the linker issues an error in such a case.
I didn't try, but a solution may be with dlopen(), dlsym() and dlclose() which allow you to programmatically handle dynamic libraries. If you don't need the two functions at the same time, you could open the first library, use the first function and close the first library before using the second library/function.
Assuming that you use linux you first need to add
#include <dlfcn.h>
Declare function pointer variable in proper context, for example,
int (*alternative_server_init)(int, char **, char **);
Like Ferruccio stated in https://stackoverflow.com/a/678453/1635364 ,
load explicitly the library you want to use by executing (pick your favourite flags)
void* dlhandle;
void* sym;
dlhandle = dlopen("/home/jdoe/src/libwhatnot.so.10", RTLD_NOW|RTLD_LOCAL);
Read the address of the function you want to call later
sym = dlsym(dlhandle, "conflicting_server_init");
assign and cast as follows
alternative_server_init = (int (*)(int, char**, char**))sym;
Call in a similar way than the original. Finally, unload by executing
dlclose(dlhandle);
Swear? As far as I am aware, there isn't much you can do if you have two libraries that expose link points with the same name and you need to link against both.
This problem is the reason c++ has namespaces. There's not really a great solution in c for 2 third party libs having the same name.
If it's a dynamic object, you might be able to explicitly load the shared objects (LoadLibrary/dlopen/etc) and call it in that fashion. Alternately, if you don't need both libs at the same time in the same code, you can maybe do something with static linking (if you have the .lib/.a files).
None of these solutions apply to all projects, of course.
You should write a wrapper library around one of them.
Your wrapper library should expose symbols with unique names, and not expose the symbols of the non-unique names.
Your other option is to rename the function name in the header file, and rename the symbol in the library object archive.
Either way, to use both, it's gonna be a hack job.
The question is approaching a decade old, but there are new searches all the time...
As already answered, objcopy with the --redefine-sym flag is a good choice in Linux. See, for example, https://linux.die.net/man/1/objcopy for full documentation. It is a little clunky because you are essentially copying the entire library while making changes and every update requires this work to be repeated. But at least it should work.
For Windows, dynamically loading the library is a solution and a permanent one like the dlopen alternative in Linux would be. However both dlopen() and LoadLibrary() add extra code that can be avoided if the only issue is duplicate names. Here the Windows solution is more elegant than the objcopy approach: Just tell the linker that the symbols in a library are known by some other name and use that name. There a few steps to doing it. You need to make a def file and provide the name translation in the EXPORTS section. See https://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx (VS2015, it will eventually get replaced by newer versions) or http://www.digitalmars.com/ctg/ctgDefFiles.html (probably more permanent) for full syntax details of a def file. The process would be to make a def file for one of the libraries then use this def file to build a lib file and then link with that lib file. (For Windows DLLs, lib files only are used for linking, not code execution.) See How to make a .lib file when have a .dll file and a header file for the process of building the lib file. Here the only difference is adding the aliases.
For both Linux and Windows, rename the functions in the headers of the library whose names are being aliased. Another option that should work would be, in files referring to the new names, to #define old_name new_name, #include the headers of the library whose exports are being aliased, and then #undef old_name in the caller. If there are a lot of files using the library, an easier alternative is to make a header or headers that wraps the defines, includes and undefs and then use that header.
Hope this info was helpful!
I've never used dlsym, dlopen, dlerror, dlclose, dlvsym, etc., but I'm looking at the man page, and it gives an example of opening libm.so and extracting the cos function. Does dlopen go through the process of looking for collisions? If it doesn't, the OP could just load both libraries manually and assign new names to all the functions his libraries provide.
If it's a builtin function.
for example, torch has range method(deprecated)and builtin has range method as well.
I was having some issues and all it took was adding __builtins__ before the function name.
range() => torch
builtins.range()
Shouldn't be hard, right? Right?
I am currently trawling the OpenAFS codebase to find the header definition of pioctl. I've thrown everything I've got at it: checked ctags, grepped the source code for pioctl, etc. The closest I've got to a lead is the fact that there's a file pioctl_nt.h that contains the definition, except it's not actually what I want because none of the userspace code directly includes it, and it's Windows specific.
Now, I'm not expecting you to go and download the OpenAFS codebase and find the header file for me. I am curious, though: what are your techniques for finding the header file you need when everything else fails? What are the worst case scenarios that could cause a grep for pioctl in the codebase to not actually come up with anything that looks like a function definition?
I should also note that I have access to two independent userspace programs that have done it properly, so in theory I could do an O(n) search for the function. But none of the header files pop out to me, and n is large...
Edit: The immediate issue has been resolved: pioctl() is defined implicitly, as shown by this:
AFS.xs:2796: error: implicit declaration of function ‘pioctl’
If grep -r and ctags are failing, then it's probably being defined as the result of some nasty macro(s). You can try making the simplest possible file that calls pioctl() and compiles successfully, and then preprocessing it to see what happens:
gcc -E test.c -o test.i
grep pioctl -C10 test.i
There are compiler options to show the preprocessor output. Try those? In a horrible pinch where my head was completely empty of any possible definition the -E option (in most c compilers) does nothing but spew out the the preprocessed code.
Per requested information: Normally I just capture a compile of the file in question as it is output on the screen do a quick copy and paste and put the -E right after the compiler invocation. The result will spew preprocessor output to the screen so redirect it to a file. Look through that file as all of the macros and silly things are already taken care of.
Worst case scenarios:
K&R style prototypes
Macros are hiding the definition
Implicit Declaration (per your answer)
Have you considered using cscope (available from SourceForge)?
I use it on some fairly significant code sets (25,000+ files, ranging up to about 20,000 lines in a file) with good success. It takes a while to derive the file list (5-10 minutes) and longer (20-30 minutes) to build the cross-reference on an ancient Sun E450, but I find the results useful.
On an almost equally ancient Mac (dual 1GHz PPC 32-bit processors), cscope run on the OpenAFS (1.5.59) source code comes up with quite a lot of places where the function is declared, sometimes inline in code, sometimes in headers. It took a few minutes to scan the 4949 files, generating a 58 MB cscope.out file.
openafs-1.5.59/src/sys/sys_prototypes.h
openafs-1.5.59/src/aklog/aklog_main.c (along with comment "Why doesn't AFS provide these prototypes?")
openafs-1.5.59/src/sys/pioctl_nt.h
openafs-1.5.59/src/auth/ktc.c includes a define for PIOCTL
openafs-1.5.59/src/sys/pioctl_nt.c provides an implementation of it
openafs-1.5.59/src/sys/rmtsysc.c provides an implementation of it (and sometimes afs_pioctl() instead)
The rest of the 184 instances found seem to be uses of the function, or documentation references, or release notes, change logs, and the like.
The current working theory that we've decided on, after poking at the preprocessor and not finding anything either, is that OpenAFS is letting the compiler infer the prototype of the function, since it returns an integer and takes pointer, integer, pointer, integer as its parameters. I'll be dealing with this by merely defining it myself.
Edit: Excellent! I've found the smoking gun:
AFS.xs:2796: error: implicit declaration of function ‘pioctl’
While the original general question has been answered, if anyone arrives at this page wondering where to find a header file that defines pioctl:
In current releases of OpenAFS (1.6.7), a protoype for pioctl is defined in sys_prototypes.h. But that the time that this question was originally asked, that file did not exist, and there was no prototype for pioctl visible from outside the OpenAFS code tree.
However, most users of pioctl probably want, or are at least okay with using, lpioctl ("local" pioctl), which always issues a syscall on the local machine. There is a prototype for this in afssyscalls.h (and these days, also sys_prototypes.h).
The easiest option these days, though, is just to use libkopenafs. For that, include kopenafs.h, use the function k_pioctl, and link against -lkopenafs. That tends to be a much more convenient interface than trying to link with OpenAFS libsys and other stuff.
Doesn't it usually say in the man page synopsis?