Where is the source code for the GNU C library? - c

How do I go about finding the source code behind standard C functions (under Linux/Ubuntu 13)?
Case in point, chdir(). I know I have to #include <unistd.h> but then I encounter a bug, and I suppose the source code would help me figure out this bug.
Thanks if you point me out to the correct source - but real thanks if you give me a method for finding the correct source file every time I need one.

The project is online at GNU C Library.

Yes, the source code to the GNU libc is available at https://sourceware.org/git/?p=glibc.git;a=tree

Related

Read libsmbios Library Documentation

I have never been good at reading and understanding C & C++ Library documentation, for some reason. It's drives me insane. If I see a working sample then I'm good for most other things.
I have installed libsmbios-dev and libsmbios-doc on my ubuntu based machine.
The Library docs are located at /usr/share/doc/libsmbios-doc/doxygen/libsmbios_c
Can anyone provide a working example of pulling the service tag number on a dell machine using libsmbios?
I've search and I can't seem to find what i'm looking for.
Thank you
Could this function be the one you're looking for?
char *sysinfo_get_service_tag();
Defined in service_tag.c, declared in system_info.h. I am unable to test this, but you would presumably include this file in your code.
#include <smbios_c/system_info.h>
at the top of your code:
#include <smbios_c/system_info.h>
when you want to obtain the service tag, in your program.
just call the function, from the library, that performs the desired operation. I.E.
sysinfo_get_dell_system_id();
which returns an int that is the system ID
There is no need to have the source code, as the executable function is in the library. libsmbios-def, which you will need to include in your link step.

how can get lib functions bodies in C?

As you can see above,I want to know how library functions (like printf) are made in C. I am using the borlandC++ compiler.
They are defined in lib files (***.lib), header files only have prototypes.
Lib files cannot be read in text editors.
So, please let me know how they could read?
C is a compiled language, so the C source code gets translated to binary machine-language code.
Because of that, you can't see the actual source code of any given library you have.
If you want to know how it works, you can see if it's an open source library, find the source code of the particular revision that generated the version you're using, and read it.
If it's not open source, you could try decompiling - use a tool that tries to guess what the original source code could have been like for generating the machine code your library has. As you can guess, this is not an accurate process - compiling isn't an isomorphic process - and, as you probably wouldn't have guessed, it could be illegal - but I'm not really sure what conditions it depends on, if any.

Including a personal.h library in C code callable from R

I've been struggling to find proper information on the web to solve this problem, in case it is an easy task please guide me through.
My final goal is to write some R functions that call C subroutines with the .Call function. In general there are no problems in doing this when R.h and Rinternals.h are sufficient.
My problem is: I would need to use in the C code some functions that are in a "personal.h" C library. I already compiled this library with gcc, but if I just try to add
#include "personal.h"
at the beginning after
#include <R.h>
#include <Rinternals.h>
like I would do if it was a standalone C file, when I then call any function from that package in the code, while compiling with R CMD SHLIB I get an error message telling me that it was not possible to find that function.
What should I do in order to include a C library in a C routine callable from R?
Read the "Writing R Extensions" manual which came with your copy of R.
Here, you need PKG_CPPFLAGS to tell R about your include files / headers. Later, you will need to tell it about your library.
Look at other small packages using C code as eg my digest package. And yes, there are in fact numerous tutorials on the Web for this too.

Use Xcode to Jump to Source Code of StdLib

When I ctrl-click a stdlib function such as malloc, I get taken to the definition in the header file. This is the behaviour I expect.
I have the correct Darwin source code for the stdlib as downloaded from Apple OpenSource - specifically:
Libc-763.13
These have been unpacked in /usr/src. The source for the malloc routine is here:
Libc-763.13/gen/malloc.c : line 948
So the question is, how can I teach Xcode to jump to the source when I click on malloc in one of my programs?
In the past I have generated ctags files for use in Vim which has given me this functionality. Is there a way to do something similar with Xcode?
The command+click navigation to jump to a definition should work for all symbols in all Xcode projects.
If it doesn't, this answer describes how you might be able to fix it.

What is sys/user.h used for?

I was inspecting the code of a linux application and i saw the #include in one of the code files. I tried looking it up on opengroup.org but i couldn't find it there, this is what the sys directory looks like: http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/ . I guess it's not standard header file, but i checked it in my /usr/include/sys and it was there.
What does it do and what it is used for ? If you can provide me with some manual for it, i would be grateful. Thanks.
Used in conjunction with ptrace(2) (see PTRACE_PEEKUSER): http://linux.die.net/man/2/ptrace
The comment at the top of the header pretty much says it all:
#ifndef _SYS_USER_H
#define _SYS_USER_H 1
/* The whole purpose of this file is for GDB and GDB only. Don't read
too much into it. Don't use it for anything other than GDB unless
you know what you are doing. */
GNU specific extensions are usually pretty easy to identify (e.g. _GNU_SOURCE). However, debugging and instrumentation has to work even if those extensions aren't turned on. For instance, people want to use GDB on code that does not #define _GNU_SOURCE.
In that case, stuff that is not defined in ISO C (and not required by POSIX) is usually clearly labeled as such.
You'll also find all kinds of strange looking symbols in programs that include the Valgrind headers.

Resources