Sources for functions like malloc()

[Blue Ocean]

Hey all, I have another question. I may seem like a moron here, but
where can I find out how C-standard functions like malloc() and
printf() are declared? I know that I can find on my computer their .h
files, but I can't find the .c files anywhere. Are they already in
object code or something? Can I disassemble them to see how they are
written?

 

[Joona I Palaste]

Hey all, I have another question. I may seem like a moron here, but
where can I find out how C-standard functions like malloc() and
printf() are declared? I know that I can find on my computer their .h
files, but I can't find the .c files anywhere. Are they already in
object code or something? Can I disassemble them to see how they are
written?

This depends entirely on the compiler. The source might not be written
in C at all. Other than that, the compiler vendor might hold the source
as proprietary, and not publish it openly. The source is available for
some compilers, for example GCC, but not for others, like (I presume)
the Microsoft compilers.

 

[Dan Pop]

Hey all, I have another question. I may seem like a moron here, but
where can I find out how C-standard functions like malloc() and
printf() are declared? I know that I can find on my computer their .h
files,

Then, use them. They are usually in human readable format and they
contain exactly what you want: the declarations of the standard library
functions.

but I can't find the .c files anywhere.

You don't need them, as long as you're looking for function declarations.

Are they already in object code or something?

They are already compiled and bundled into libraries of object code.
Ready to be used by your linker.

Can I disassemble them to see how they are written?

You can use your librarian utility to extract modules from libraries and
you can even disassemble them, but it is highly unlikely that you will
learn anything about the implementation of the respective functions from
this exercise (except for very simple functions, like strlen or memcpy).
If you're an assembly wizard, you can even try your hand at more complex
functions, but printf and malloc are about the last you may want to try.

Better options are:

1. Get a copy of Plauger's "The Standard C Library". The code is clean,
well commented and documented. Even if it's not the same as the one
used by your implementation, it's much easier to understand how it
works.

2. Try to find out if the source code of your libraries is available.
Some implementations make it available, either for free or for a price.
Even if this is the case, the first option is generally better (reading
the glibc source code is certainly not for the faint of heart).

Dan

 

[Dan Pop]

This depends entirely on the compiler. The source might not be written
in C at all. Other than that, the compiler vendor might hold the source
as proprietary, and not publish it openly. The source is available for
some compilers, for example GCC, but not for others, like (I presume)
the Microsoft compilers.

Do you *really* expect the gcc sources to contain implementations of
printf and malloc? Are you unable to tell the difference between a
compiler and an implementation of the standard C library?

Dan

 

[Rich Gibbs]

Blue Ocean said the following, on 07/06/04 10:56:

Hey all, I have another question. I may seem like a moron here, but
where can I find out how C-standard functions like malloc() and
printf() are declared? I know that I can find on my computer their .h
files, but I can't find the .c files anywhere. Are they already in
object code or something? Can I disassemble them to see how they are
written?

I think you have some slight confusion about terminology here. The '.h'
files _do_ contain _declarations_ of the standard library functions.

Depending on the compiler/platform you are using, some standard library
functions may not be implemented in C; they might, for example, be in
assembler. Some implementations, such as the GNU compiler 'gcc', have
source code available for their libraries. Others make available only
the compiled libraries suitable for linking with your programs.

If you would like to understand more about how the library is or can be
implemented, I recommend P.J. Plauger's excellent book, _The Standard C
Library_. It contains an implementation of the library in C, and also a
discussion of what the standard requires, and of portability
considerations. I think you would find it a very valuable aid to
understanding.

 

[Joona I Palaste]

Do you *really* expect the gcc sources to contain implementations of
printf and malloc? Are you unable to tell the difference between a
compiler and an implementation of the standard C library?

Dan(g), I wasn't thinking straight. Thanks for correcting me, Dan. Of
course the sources of GCC are free - but they don't contain the
standard library sources, as you said. However, at least Linux uses
"libc" as its standard library, and its sources are also free. libc
and GCC don't have anything to do with each other, at least legally.

 

[William Ahern]

Hey all, I have another question. I may seem like a moron here, but
where can I find out how C-standard functions like malloc() and
printf() are declared? I know that I can find on my computer their .h
files, but I can't find the .c files anywhere. Are they already in
object code or something? Can I disassemble them to see how they are
written?

Aside from the previous corrections and suggestions (a good book can be
invaluable), the OpenBSD sources (and I'm sure NetBSD) are pretty clean-cut:

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/

If you dive into GCC or glibc you might drown. You can get lost in the
assembly, I18N, SYSV & POSIX.2 & BSD emulation, Linux'isms, etc.

Keep in mind that the internals of malloc(), printf() and the like can
differ widely; you can easily screw yourself by getting chummy w/ them. Keep
a copy of the ISO C standard at hand to stay afloat.

Even better than looking at other sources is trying to emulate the behavior
of the above w/o peeking at what others did. Seeing somebody's answers can
undermine your ability to truly understand the problem(s) and to be readily
able to imagine alternatives.

 

[Blue Ocean]

Hey all, I have another question. I may seem like a moron here, but
where can I find out how C-standard functions like malloc() and
printf() are declared? I know that I can find on my computer their .h
files, but I can't find the .c files anywhere. Are they already in
object code or something? Can I disassemble them to see how they are
written?

[snip]

If you dive into GCC or glibc you might drown. You can get lost in the
assembly, I18N, SYSV & POSIX.2 & BSD emulation, Linux'isms, etc.

Well, I'll take your advice there, since I only know what one of those
things actually is (assembly). I am a rising sophmore computer
science student at university. Any guesses as to when I'll pick up
the rest of that? I know it sounds silly but I desire to know
everything about programming, eventually. Or, if not everything, as
absolutely close as possible, and that includes knowing what it would
take to eventually be able to write my own operating system (not that
anything will ever come to that, but I want to come to the point where
I know I could if I had to, however rudimentary it might be).

Keep in mind that the internals of malloc(), printf() and the like can
differ widely; you can easily screw yourself by getting chummy w/ them. Keep
a copy of the ISO C standard at hand to stay afloat.

I don't plan to get chummy. =) I wanted to look for curiosity's
sake, because I'd like to see the algorithms.

Even better than looking at other sources is trying to emulate the behavior
of the above w/o peeking at what others did. Seeing somebody's answers can
undermine your ability to truly understand the problem(s) and to be readily
able to imagine alternatives.

To do that, wouldn't I have to design a layer of abstraction? I'm
doing something like that right now in Java. I've got it to the point
where I have a rudimentary assembly language and a representation of
memory and registers, and a gui that can show all of that to the user.
I intend to eventually create a thread scheduler, dynamic memory
allocator, and some other things, but I don't know if I'll ever get
around to writing a scripting language to go on top of all of that
that could be compiled.

Also, to everyone else, forgive me for my incorrect use of the word
"declare." I did indeed mean "define."

 

[Dan Pop]

Dan(g), I wasn't thinking straight. Thanks for correcting me, Dan. Of
course the sources of GCC are free - but they don't contain the
standard library sources, as you said. However, at least Linux uses
"libc" as its standard library, and its sources are also free. libc
and GCC don't have anything to do with each other, at least legally.

You must be talking about glibc, as libc is the generic Unix name of the
main C library, containing most of the standard library functions, as well
as tons of Unix-specific stuff.

gcc is not connected to glibc (it works on many systems where glibc is not
available) but glibc is strongly tied to gcc, i.e. it is NOT written in C
and it uses even the most obscure and undocumented features of both GNU C
and gcc. Many parts of glibc look like complete gibberish to the
standard C programmer.

So, don't recommend things you're not familiar with!

Dan

 

[Thomas Matthews]

Hey all, I have another question. I may seem like a moron here, but
where can I find out how C-standard functions like malloc() and
printf() are declared? I know that I can find on my computer their .h
files, but I can't find the .c files anywhere. Are they already in
object code or something? Can I disassemble them to see how they are
written?

[snip]

If you dive into GCC or glibc you might drown. You can get lost in the
assembly, I18N, SYSV & POSIX.2 & BSD emulation, Linux'isms, etc.

Well, I'll take your advice there, since I only know what one of those
things actually is (assembly). I am a rising sophmore computer
science student at university. Any guesses as to when I'll pick up
the rest of that? I know it sounds silly but I desire to know
everything about programming, eventually. Or, if not everything, as
absolutely close as possible, and that includes knowing what it would
take to eventually be able to write my own operating system (not that
anything will ever come to that, but I want to come to the point where
I know I could if I had to, however rudimentary it might be).

Keep in mind that the internals of malloc(), printf() and the like can
differ widely; you can easily screw yourself by getting chummy w/ them. Keep
a copy of the ISO C standard at hand to stay afloat.

I don't plan to get chummy. =) I wanted to look for curiosity's
sake, because I'd like to see the algorithms.

There is a whole lot of information about memory allocation
strategies. For algorithms, use your favorite search engine
and these terms "memory allocation algorithm". Perhaps also
"garbage collection algorithm". After all, the malloc() family
are just memory allocation functions.

Many courses in Operating Systems will review some memory
allocation algorithms. There is no single memory allocation
strategy that fits all. There are a whole bunch so that one
can choose the ones that best fit the situation.

For algorithmic discussions, use
--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Joona I Palaste]

You must be talking about glibc, as libc is the generic Unix name of the
main C library, containing most of the standard library functions, as well
as tons of Unix-specific stuff.

Yes, that's what I was thinking about.

gcc is not connected to glibc (it works on many systems where glibc is not
available) but glibc is strongly tied to gcc, i.e. it is NOT written in C
and it uses even the most obscure and undocumented features of both GNU C
and gcc. Many parts of glibc look like complete gibberish to the
standard C programmer.

Well, if we replace libc with glibc, I was right in saying that the
sources are freely available. But I was wrong in saying GCC and glibc
don't have anything to do with *each other*.

So, don't recommend things you're not familiar with!

How else could I get you to correct my mistakes? =)

 

[Dan Pop]

Dan Pop <[email protected]> scribbled the following:

How else could I get you to correct my mistakes? =)

I'd rather spend my time posting answers than correcting other people's
incorrect answers.

If you *know* the answer to a question, post it. If you don't, let
other people do it, rather than assume that you're the OP's last hope.

Dan

 

[William Ahern]

<snip>
Well, I'll take your advice there, since I only know what one of those
things actually is (assembly). I am a rising sophmore computer
science student at university. Any guesses as to when I'll pick up
the rest of that?

When you need to, and no sooner Patience is a virtue.

POSIX.2, "SYSV" and "BSD" are intersecting sets of Unix C programming APIs.
If you're on a Unix system thumb through the man pages and you'll see
references. I18N is short for internationalization, a generic moniker for
the process of making software portable across language and custom.

http://en.wikipedia.org/wiki/POSIX
http://en.wikipedia.org/wiki/I18n

GCC and glibc try to be lots of things to lots of people, and most of the
developers have been around the block quite a few times. Over time you'll
become acquainted w/ all the things its riddled w/, but for the
uninitiated--including myself--its usually not well suited for exhibition.

http://www.gnu.org/doc/doc.html

I know it sounds silly but I desire to know
everything about programming, eventually. Or, if not everything, as
absolutely close as possible, and that includes knowing what it would
take to eventually be able to write my own operating system (not that
anything will ever come to that, but I want to come to the point where
I know I could if I had to, however rudimentary it might be).

<snip>

Since we're on comp.lang.c, I'll just suggest to listen intently to these
folks. Some people mistake their preciseness as unneccessary pedantism, but
if you stick around long enough you learn that precision is important unto
itself.

As far as C is concerned, stick to the ANSI/ISO standards.

http://rm-f.net/standards/
http://oakroadsystems.com/tech/c-predef.htm

If you can't solve your particular problem from there (and most of the time
you can), then drop down a level to another standard; something like
POSIX.2/SUSv3--Standard Unix Specification--if you're on a Unix.

http://www.unix.org/version3/online.html

If you still can't solve your problem satisfactorily, then resort to
non-standard but reasonably portable interfaces. Those are sometimes
difficult to find. snprintf() was sort of in this boat prior to the
C99 standard.

Then resort to platform or environment specific features.

This is a rule of thumb (not only just for C programming). Ultimately the
point is that an affinity for standards, idioms and established practices
keeps you anchored and focused so that you can progress smoothly. They
equally provide a reference for things they never mention by virtue of
defining a landscape. Similarly--for somebody who has the faintest bit of
curiosity and can read--the extremely dangerous but standardized gets()
function in standard C provides an excellent, concrete example how _not_ to
do something. In this sense, a standard serves as an enabler of productive
discourse.

Of course, there's no substitute for coding, coding, coding. But it seems
you already recognize that.

 

[LibraryUser]

Aside from the previous corrections and suggestions (a good book
can be invaluable), the OpenBSD sources (and I'm sure NetBSD) are
pretty clean-cut:

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/

.... snip ...

Piggybacking here, since the original is no longer available.
You can also find the source for malloc, free, realloc, and some
auxiliary optional debug modules at:

<http://cbfalconer.home.att.net/download>

Look for the "nmalloc.zip" package.

 

[Dan Pop]

POSIX.2, "SYSV" and "BSD" are intersecting sets of Unix C programming APIs.

Last time I checked POSIX.2 was dealing with the command line utilities.
It is POSIX.1 that deals with the API.

Dan