Internals of the printf function?

hey all, im a new programmer.

i was wondering how you would go about writing the printf function yourself? it is my understanding that when you call printf you are calling an already written function and just providing an argument? if this is the case, is it possible to write that function yourself with just the bare primitives of the language? i only want to know because i am curious about how things like that work.

---------- Post updated 05-01-10 at 01:19 AM ---------- Previous update was 04-30-10 at 10:05 PM ----------

just to update, i've researched that the gcc compiler is written mostly in C, and so it's likely that the code for all these built-in c functions are written in C as well. so i take that to mean i could somehow write a printf-like function.

i suppose my best bet would be to look at the gcc source and just find it. however, not being a good programmer yet ( i only started just last week), i have no idea where i would find it :D. if anyone could point me in the right direction, or explain how i might write it, i would be very happy :smiley:

try here:
GNU C Library - GNU Project - Free Software Foundation (FSF)

Note that GNU source is a big project with lots of interdependent modules.

FYI - the UNIX kernel, most UNIX tools are written in C, the cc compiler is written in C, so is the C runtime (like printf).

Se 'man stdarg' for info on how it handles varying numbers of arguments.

Ya why not you can definitely write your own versions. Now a small correction , its the stdio library under the glib which defines this printf() and not the gcc. The archieve file /usr/lib/libc.a contains an object (printf.o) inside its archive which has the exact function definition for the printf() function; which is normally linked statically into your program at the link time (again not by 'gcc' directly but the 'ld' itself).

The prototype of printf() looks like the following:

extern int printf (const char *__restrict __format, ...);

Its taking one const string and a variable number of arguments.

Use varg_ macros to built incremently your own version of printf() library.
:slight_smile:

There is no stdio library under glib. In fact there is nothing called glib! There is a header called <stdio.h> which is defined by ISO C, IEEE 1003.1 by incorporation, SUS3 by incorporation, etc. Note that there is no requirement for <stdio.h> to actually be a file - hence the term "header" instead of "header file".

Ya, stdio.h is just a header. However, as of glib reference, I expected that its the usual reference to the set of c-libraries available under /usr/lib/* . Please re-confirm me, if its not.

Its a fact that gcc/g++ is capable of attaching stdio.h headers, by default -if not specified and is no longer a requirement for a source code to explicitly add it. I, however, thought that its a feature implemented only under gcc and didn't know that its now a standard proposed.

Thanks.

Unless this is an extremely recent feature, I think there's some confusion there, I've never heard of gcc including stdio.h by default anywhere. In fact I often need to add it to code where people didn't bother, since this causes not just compiler warnings but runtime segmentation faults on systems where int and void * are different sizes.

It definitely links stdio by default, but so do nearly all C linkers, and that's not the same thing as including the header.

All headers are explicitly required - corona points this out clearly.

More important - when you compile:
1.warnings cannot be there. Ever. Period.
2. use -Wall to identify problems - if not gcc, then use lint.

gcc-Wall myfile.c

corona gave a great example why you cannot tolerate warnings.

Any implicitly defined (meaning it was not explicitly defined like

int somefunc(char*, int, ...);

either in your code or in a header file)
is trouble waiting to happen. If your code happens to work for a while it is called 'coding by coincidence' and is both dangerous and hard to debug.

Please consider never running code that does not compile perfectly.

It is not so.