for example, the strrev() function. i know that it's declared in string.h, and i wanna to figure out how it is implemented. so where could i the source code?
OS: Windows XP SP3
IDE: Pelles C 6.50 RC3
If you just want to see the source to an implementation of the standard C library (albeit one that is in wide use), the source to glibc is available. You can clone the git repository:
git clone git://sourceware.org/git/glibc.git
You can also examine the source in a browser. Here's the string library, for instance.
glibc does not include strrev(). However, if you Google for
strrev c
you'll get hits to various implementations. For example: http://www.cas.mcmaster.ca/~kahl/SE2S03/2006/C/strrev.c and ftp://ftp.ecs.vuw.ac.nz/pub/libs/libstrings/strrev.c.
It depends where your particular compiler puts it. Many compilers don't provide the library source code.
Related
Is there some clear-cut distinction between standard C *.h header files that are provided by the C compiler, as oppossed to those which are provided by a standard C library? Is there some list, or some standard locations?
Motivation: int this answer I got a while ago, regarding a missing unistd.h in the latest TinyC compiler, the author argued that unistd.h (contrarily to sys/unistd.h) should not be provided by the compiler but by your C library.
I could not make much sense of that response (for one thing shouldn't that also apply to, say, stdio.h?) but I'm still wondering about it. Is that correct? Where is some authoritative reference for this?
Looking in other compilers, I see that other "self contained" POSIX C compilers that are hosted in Windows (like the GCC toolchain that comes with MinGW, in several incarnations; or Digital Mars compiler), include all header files.
And in a standard Linux distribution (say, Centos 5.10) I see that the gcc package provides a few header files (eg, stdbool.h, syslimits.h) in /usr/lib/gcc/i386-redhat-linux/4.1.1/include/, and the glibc-headers package provides the majority of the headers in /usr/include/ (including stdio.h, /usr/include/unistd.h and /usr/include/sys/unistd.h).
So, in neither case I see support for the above claim.
No, there is no clear-cut distinction.
As far as the C standard is concerned (here's a recent draft), the compiler and the library together make up the implementation, distinguished mostly by being described in sections 6 and 7 of the standard, respectively.
For some implementations, the compiler and the runtime library are provided by the same vendor/organization/person, either as a single installable package or as two separate packages. For other implementations (including gcc), the bulk of the standard library is provided by the underlying operating system, but the installation package for the compiler includes a few of its own headers.
Another example: When you install gcc from source on Solaris, the installer runs a script that grabs copies of some of the existing header files (provided by Sun's Oracle's runtime library) and edits them, installing the modified copies in a separate directory.
On GNU/Linux systems, the default C compiler is usually gcc, and the runtime library is provided by glibc -- both GNU packages, but developed separately. The MinGW implementation under Windows uses the gcc compiler with Microsoft's runtime library (which leads to some problems because they disagree on the representation of long double).
The choice of which standard headers need to be provided by the compiler is made by the authors of the compiler. Headers whose implementation is tightly tied to a particular compiler (such as <stdint.h>, <limits.h>, and <float.h>) are typically provided by the compiler; headers that provide an interface to operating system services, like <stdio.h> and <stdlib.h> are typically provided by the runtime library or perhaps by the OS.
The C standard provides no direct guidance regarding how this choice should be made.
Except for embedded (free-standing) C implementations, it makes little sense to separate C into compiler and libraries. Neither a compiler without libraries, not a C library without a compiler make much sense. Only a compiler together with a library makes up a complete implementation.
Since C89, the standard library is part of the C standard, and the list of required header files is listed in the standard. Other sets of libraries are standardized by Posix, X/Open ...
See this answer for a list: List of standard header files in C and C++
There are some headers that are by nature closer to the compiler itself, e.g. limits.h, which specifies the size of the data types. Some headers are closer to the OS, i.e. unistd.h. In both cases however, there are intersections, and if the OS' idea of, say, size_t and the compiler's implementation do not agree, nothing will work.
One could also argue that unistd.h should be provided by the OS and not by the C library - after all, the knowledge how to call a kernel function belongs into the OS.
In summary, I think this distinction into compiler, C library, operating system makes little sense.
I am using a Linux operating system and the library functions I am talking about C programming language.
Those functions are part of the system's C library, which on most GNU/Linux systems is GNU libc, also known as "glibc". Since glibc is open-source free software, you can download its source code and read whatever parts you're interested in. The download page is the place to start.
Look at the source code for the open source C libraries. There is glibc, bionic, uclibc and BusyBox.
You can download the source code of Glibc, the C library used by most Linux distributions.
It might be a little more complex than you anticipated, though. It might be more helpful to take a look at a simpler C library, if you are interested in how it works in principle. I'd suggest libctiny for that.
You can browse the glibc code online from the following location:
http://bazaar.launchpad.net/~vcs-imports/glibc/master/files
http://bazaar.launchpad.net/~vcs-imports/glibc/master/files/head:/stdlib/
Doug Lea Malloc
ftp://g.oswego.edu/pub/misc/malloc.c
The C library used on most Linux systems is glibc which is:
the GNU Project's implementation of the C standard library
and you can browse the git repository online and you can find the download instructions here.
My suggestion is don't go to see the whole code of any predefined function else you have a very positive reason for that. It is better to see the manual page. To check in manual we have different section and these are
1) simple linux shell scripting command
2) system calls e.g. fork etc
3) C functions, all predefined function.
7) Some definition of the function
man printf this will redirect you to manual page 1 means you will see the printf of shell scripting
to check for printf c predefined function check
man 3 printf
Ok here's the thing.
Most people learn about the C standard library simultaneously as they first get in contact with the C language and I wasn't an exception either. But as I am studying linux now, I tend to get confused with C libraries. well first, I know that you get a nice old C standard lib as you install gcc on your linux distro as a static lib. After that, you get a new stable version of glibc pretty soon as you connect to the internet.
I started to look into glibc API and here's where I got messed up. glibc seems to support vast amount of lib basically starting from POSIX C Standard lib (which implements the standard C lib(including C99 as I know of)) to it's own extensions based on the POSIX standard C lib.
Does this mean that glibc actually modified or added functions in the POSIX C Standard lib? or even add whole new header set? Cause I see some functions that are not in the standard C lib but actually included in the standard C header (such as strnlen() in
Also referring to what I mentioned about a 'glibc making whole new header set', is because I'm starting to see some header files that seems pretty unique such as linux/blahblah.h or sys/syscalls.h <= (are these the libs that only glibc support?)
Next Ques is that I actually heard linux is built based on C language. Does this mean linux compiles itself with it's own gcc compiler???????
For the first question, glibc follows both standard C and POSIX, from About glibc
The GNU C Library is primarily designed to be a portable and high performance C library. It follows all relevant standards including ISO C11 and POSIX.1-2008. It is also internationalized and has one of the most complete internationalization interfaces known.
For the second question, yes, you can compile Linux using gcc. Even gcc itself can be compiled using gcc, it's called bootstrapping.
Glibc implements the POSIX, ANSI and ISO C standards, and adds its own 'fluff', which it calls "glibc extensions". The reason that they are all "mixed together" is because they wrote the library as one package, there is no separate POSIX-only glibc.
<linux/blah> is not part of glibc. It is a set headers written specifically for the operating system, by people outside of glibc, to give the programmer access to the Linux kernel API. It is "part" of the Linux kernel and is installed with it, and is used for kernel hacking. <sys/blah> is part of glibc, and is specific to Linux. It gives access to a fairly abstracted Linux system API.
As for your second question, yes. Linux is written in C, as it is (according to Linus) the only programming language for kernel and system programming. The way this is done is through a technique called bootstrapping, where a small compiler is built (usually manually in ASM) and builds the entire kernel or the entirety of GCC.
There is one more thing to be aware of: one of the purposes of the libc is to abstract from the actual system kernel. As such, the libc is the one part of your app that is kernel specific. If you had a different kernel with different syscalls, you would need to have a specially compiled libc. AFAIK, the libc is therefore usually linked as a shared library.
On linux, we usually have the glibc installed, because linux systems usually are GNU/Linux systems with a GNU toolchain on top of the linux kernel.
And yes, the glibc does expand the standards in certain spots: The asprintf() function for instance originated as a gnu-addition. It almost made it into the C11 standard subsequently, but until it becomes part of them, it's use will require a glibc-based system, or statically linking with the glibc.
By default, the glibc headers do not define these gnu additions. You can switch them on by defining the preprocessor macro GNU_SOURCE before including the appropriate headers, or by specifying -std=gnu11 to the gcc call.
I'm looking for the whole source code of all the C standard libraries. That said, I'm looking for the source code of stdio.h, stdlib.h, string.h, math.h, etc... I would like to see how they were created. I think that it depends from platform to platform, but Linux or Windows one will be welcomed.
If you want the actual implementations, as everyone else has assumed you don't, many Linux distributions currently use glibc to implement the C standard library. Common alternatives include musl libc, diet libc, uClibc, and Bionic
PJ Plauger wrote a book about the standard C library. Includes references from the (now dated) standard, and source code.
Microsoft Visual Studio generally has the system headers under <InstallDir>\VC\include, and the source, if installed, is under <InstallDir>\VC\crt\src.
Whether its installed with an IDE or you have installed explicitly, you have to look in the directory "Include" in respective location.
Ex: I use MinGW. So, I would go to
c:/MinGW/include to find those header files. Similarly, for an IDE (say Dev-cpp), you need to go to c:/dev-cpp/include.
I study C and I noticed that I can't find the implementation file for some header files like, for example, stdio.h which is a library which contains a lot of input/output functions, like printf. Where can I find its implementation?
Download one of these:
glibc
uclibc
dietlibc
BSD libc
Or, even better, download several of these and compare their implementations. Of course, these are likely doing a lot of things different compared to your particular standard library implementation, but would still be quite interesting for e.g. non-platform-specific functionality such as sprintf.
You need to find the source code for a C standard library like glibc: http://www.gnu.org/s/libc/
You can download the source here: http://ftp.gnu.org/gnu/glibc/
It contains source for all the library functions.
For example here. Google is your friend - just search for stdio.c. But note that you should handle these as "one implementation of many possible" - you don't know how your compiler is doing it by reading those, you just get an idea of how it can be done.
On Ubuntu or other OS that uses aptitude for package management, you can use:
apt-get source libc6
for example.
Also, running gcc in verbose mode will tell you the details of the paths it is using. This should help you find which include and library paths it's using.
gcc -v
or
gcc -Wl,--verbose
If you install the Windows SDK, there is an option to include the standard library source code, so you can also see how it is implemented on Windows.