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.
Related
Couldn't stdio functions and variables be defined in header files without having to use .c files.
If not, what are .c files used for?
The functions defined in the header file have to be implemented. The .c file contains the implementation, though these have already been compiled into a static or shared library that your compiler can use.
The header file should contain a minimal description of the function to save time when compiling. If it included the entire source it'd force the compiler to rebuild it each and every time you compile which is really wasteful since that source never changes.
In effect, the header file serves as a cheat sheet on how to interact with the already compiled library.
The reason the .c files are provided is primarily for debugging, so your debugger can step through in your debug build and show you source instead of raw machine code. In rare cases you may want to look at the implementation of a particular function in order to better understand it, or in even more rare cases, identify a bug. They're not actually used to compile your program.
In your code you should only ever reference the header file version, the .h via an #include directive.
stdio.h is a standard header, required to be provided by every conforming hosted C implementation. It declares, but does not define, a number of entities, mostly library functions like putchar and scanf.
stdio.c, if it exists, is likely to be a C source file that defines the functions declared in stdio.h. There is no requirement that an implementation must make it available. It might not even exist; for example the implementations of the functions declared in stdio.h might appear in multiple *.c files.
The declaration of putchar is:
int putchar(int c);
and that's all the compiler needs to know when it sees a call to putchar in your program. The code that implements putchar is typically provided as machine code, and the linker's job is to resolve your putchar() call so it ends up invoking that code. putchar() might not even be written in C (though it probably is).
An executable program can be built from multiple *.c source files. One and only one copy of the code that implements putchar is needed for an entire program. If the implementation of putchar were in the header file, then it would be included in each separately compiled source file, creating conflicts and, at best, wasting space. The code that implements putchar() (and all the other functions in the library) only needs to be compiled once.
The .c files has specific function for any aim. For example stdio.c files has standart input-output functions to use within C program. In stdio.h header files has function prototypes for all stdio.c functions, all defines, all macros etc. When you #include <stdio.h> in your main code.c file your main code assumes there is a " int printf(const char *format, ...)" function. Returns int value and you can pass argument ..... etc. When you call printf() function actually you use stdio.c files..
There are languages where if you want to make use of something someone else has written, you say something like
import module
and that takes care of everything.
C is not one of those languages.
You could put "library" source code in a file, and then use #include to pull it in wherever you needed it. But this wouldn't work at all, for two reasons:
If you used #include to pull it in from two different source files, and then linked the two resulting object files together, everything in the "library" would be defined twice.
You might not want to deliver your "library" code as source; you might prefer to deliver it in compiled, object form.
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.
What does include and link REALLY do? What are the differences? And why do I need to specify both of them?
When I write #include math.h and then write -lm to compile it, what does #include math.h and -lm do respectively?
In my understanding, when linking a library, you need its .h file and its .o file. Does this suggest #include math.h means take in the .h file while -lm take in the .o file?
The reason that you need both a header (the interface description) and the library (the implementation) is that C separates the two clearer than languages like C# or Java do. One can compile a C function (e.g. by invoking gcc -c <sourcefile>) which calls library code even when the called library is not present; the header, which contains the interface description, suffices. (This is not possible with C# or Java; the assemblies resp. class files/jars must be present.) During the link stage though the library must be there, even when it's dynamic, afaik.
With C#, Java, or script languages, by contrast, the implementation contains all information necessary to define the interface. The compiler (which is not as clearly separated from the linker) looks in the jar file or the C# assembly which contain called implementations and obtains information about function signatures and types from there.
Theoretically, that information could probably be present in a library written in C as well — it's basically the debug information. But the classic C compiler (as opposed to the linker) is oblivious to libraries or object files and cannot parse them. (One should remember that the "compiler" executable you usually use to compile a C program , e.g. gcc, is a "compiler driver" which interprets the command line arguments and calls the programs which actually do stuff, e.g. the preprocessor, actual compiler and actual linker, to create the desired output.)
So in theory, if you have a properly annotated library in a known location, you could probably write a compiler which compiles a C function against it without having function declarations and type definitions; the compiler would have to produce the proper declarations. The compiler would have to know which library to parse (which corresponds to setting a C# project "Reference" in VS or having a class path and name/class correspondence in Java).
It would probably be easiest to use a well-known debugging format like stabs or dwarf and extract the interface definitions from it with a little helper program which uses the API for the debug format, extracts the information and produces a C header which is prepended to every source file. That would be the job of the compiler driver, and the actual compiler would still be oblivious to that.
It's because headers files contain only declaration and .o files (or .obj, .dll or .lib) contain definitions of methods.
If you open an .h file, you will not see the code of methods, because that is in the libraries.
One reason is commercial, because you need to publish your code and have the source code in your company. Libraries are compiled, so you could publish it.
Header files only tell compiler, what classes and methods it can find in the library.
The header files are kind of a table-of-contents plus a kind of dictionary for the compiler. It tells the compiler what the library offers and gives special values readable names.
The library file itself contains the contents.
What you are asking are entirely two different things.
Don't worry , i will explain them to you.
You use # symbol to instruct the preprocessor to include the math.h header files which internally contain the function prototypes of fabs(),ceil() etc..
And you use -lm to instruct the linker, to include the pre-compiled function definitions of fabs(),ceil() etc. functions in the exe file .
Now, you may ask why we have to explicitly link library file of math functions unlike for other functions and the answer is ,it is due to some undefined historical reasons.
I am new to C language, and was wondering if there is a universal header that can be included at top of main function . In Java it is very easy just do ctrl+shift+o in eclipse and it imports packages for you. But in C, I have to google every time and add it. Sometimes, I don't even know what library to include.
Thank you very much .
There is no universal header -- since parsing every header takes time, and there are thousands (if not millions) of headers available, there is no way to include them all into every compilation unit. You wouldn't want to, since 99.9% of them wouldn't be used and would only needlessly bloat the end executable with static allocations.
Every standardized function will tell you the headers you need to include at the top of its manpage; for example, from malloc(3):
NAME
calloc, malloc, free, realloc - Allocate and free dynamic
memory
SYNOPSIS
#include <stdlib.h>
void *calloc(size_t nmemb, size_t size);
void *malloc(size_t size);
void free(void *ptr);
void *realloc(void *ptr, size_t size);
Thus you need to #include <stdlib.h> in your project, and there's the prototypes for you to see.
If you want a quick way to see the manpages, you can configure your IDE to show them to you quickly. The default keybinding for K in vim is to load the manpage for the function under the cursor -- but, since it uses the default manpage search order, it can sometimes find the wrong page. (On printf, for example, it loads printf(1) rather than printf(3). Annoying. The MANSECT environment variable described in man(1) can be used to change this behavior to show you 3 before 1, if you wish.)
There isn't a single header that is all-encompassing.
All else apart, any such header for MS Windows would be wrong for Unix, and any such header for Unix would be wrong for Windows. Even on Unix, should the universal header include all the X11 headers? What about the OpenSSL headers? What about the POSIX threads headers? Other POSIX headers?
You need to learn where to go to find the information for any given function that you need to use. On Unix, the classic resource was the 'man page' (meaning 'manual page', typically formatted with the '-man' troff/nroff macro package). These days, I tend to use the web: for example, I find POSIX man pages at The Open Group.
(Note that a header is separate from a library; there may be many headers used by the functions in a single library. See the Standard C Library as an illustration.)
There is no universal header, but you can certainly make one for your application, and include it in all your files. If you are not sure what file to include for a function that you need to call, you can use man command on UNIX. For example,
man 3 printf
shows this:
SYNOPSIS
#include <stdio.h>
int printf(const char * restrict format, ...);
If you stay with it for enough time, you usually remember the "mapping" of functions to headers relatively quickly.
No.
I suppose you could create one, but that would slow your compiles down quite a bit. Some IDEs might help you find the include files.
You can get Eclipse to automatically insert various header files you use often. But: if you want to learn C I would suggest that you do that job of finding which ones to include.
It's as with all learning. Learn by doing — learn by repetition.
The standard C library is not that huge — and the header files are intuitively named and have a manageable list of standard functions.
Have a list like this available and read it. Read it when you'll need an include etc.
When you feel you really know when and what to include. Automate it.
You are including a header file because you are using an interface defined in the header file; not because there is a standard set to include. So, how do you determine what interface you need? There are two basic options:
Find either the header files or descriptions of the header files and look through them to learn of the interfaces, or
Use 'apropos search_term' or 'man interface_function'.
As a beginner, option #1 would be a good start — look in /usr/include or find a book named 'The C Standard Library' (or something similar).
A good reference manual (such as this one) will have an appendix listing all of the library functions and their associated header file. You can also check the on-line C language standard, Chapter 7 for a similar listing.
Under the /usr/include directory in Linux i entered the command:
find -type f -name unistd.h which gave the following output:
./unistd.h
./linux/unistd.h
./asm-generic/unistd.h
./bits/unistd.h
./asm/unistd.h
./sys/unistd.h
my question is, what is the purpose of each unistd.h, since there is only one definiton of that file in the single unix specification ?
Thanks in advance.
linux/unistd.h actually points to asm/unistd.h, which in turn points to either asm/unistd_32.h or asm/unistd_64.h, which is where system call numbers are defined and presented to user space depending on the system's architecture. These come from the kernel.
bits/unistd.h is a collection of macros that augment unistd.h (mostly stuff to help prevent buffer overflows), which is conditionally included via:
/* Define some macros helping to catch buffer overflows. */
#if __USE_FORTIFY_LEVEL > 0 && defined __extern_always_inline
# include <bits/unistd.h>
#endif
In essence, the only POSIX required header is in fact, just unistd.h, the rest are either extensions, or definitions from the kernel. So, just including unistd.h is all you have to worry about doing, everything you need will be pulled in depending on your architecture and whatever build options you've selected.
It's a common technique in C and C++ - you have a single file with the "standard" name in the "standard" place, in this case ./unistd.h, and then have that file include one or more implementation specific files, depending on preprocessor macros. If you look at almost any "standard" C or C++ header files, you will see it including other files not mentioned in any standard.
Basically think of /usr/include/unistd.h as a smart symbolic link. It will point to a correct implementation depending on what your operating conditions are.
That said, it makes difficult sometimes to figure out what that correct implementation is.