I'm pretty sure that the Plauger Standard C Library book has a disc with the source of strtod.
http://www.amazon.co.uk/Standard-C-Library-P-J-Plauger/dp/0131315099
and there are online versions too:
http://www.google.co.uk/search?hl=en&client=firefox-a&hs=IvI&rls=org.mozilla%3Aen-GB%3Aofficial&q=strtod+source+code
P.J. Plauger, in his book The Standard C Library (which covers implementing the whole library) presents test programs for each part of the library. These are not exhaustive, and I don't have an on-line source for them, but the book is definitely of interest to anyone implementing the library.
If what you want is the documentation for the standard library functions, then P.J. Plauger's "The Standard C Library" http://www.amazon.com/Standard-C-Library-P-J-Plauger/dp/0131315099/ref=sr_1_1?s=books&ie=UTF8&qid=1290273108&sr=1-1 is the best reference. It's got pretty extensive annotation and comentary on the why and how of the standard.
If you read Plauger's The Standard C Library (1992), you will see that the <stdio.h> header is allowed to provide getchar() and getc() as function-like macros (with special permission for getc() to evaluate its file pointer argument more than once!). However, even if it provides macros, the implementation is also obliged to provid actual functions that do the same job, primarily so that you can access a function pointer called getchar() or getc() and pass that to other functions.
That is, by doing:
#include <stdio.h>
#undef getchar
extern int some_function(int (*)(void));
int core_function(void)
{
int c = some_function(getchar);
return(c);
}
As written, the core_function() is pretty meaningless, but it illustrates the point. You can do the same thing with the isxxxx() macros in <ctype.h> too, for example.
Normally, you don't want to do that - you don't normally want to remove the macro definition. But, when you need the real function, you can get hold of it. People who provide libraries can emulate the functionality of the standard C library to good effect.
Seldom needed
Also note that one of the reasons you seldom need to use the explicit #undef is because you can invoke the function instead of the macro by writing:
int c = (getchar)();
Because the token after getchar is not an (, it is not an invocation of the function-like macro, so it must be a reference to the function. Similarly, the first example above, would compile and run correctly even without the #undef.
If you implement your own function with a macro override, you can use this to good effect, though it might be slightly confusing unless explained.
/* function.h */
…
extern int function(int c);
extern int other_function(int c, FILE *fp);
#define function(c) other_function(c, stdout);
…
/* function.c */
…
/* Provide function despite macro override */
int (function)(int c)
{
return function(c, stdout);
}
The function definition line doesn't invoke the macro because the token after function is not (. The return line does invoke the macro.
Back in the day, I found P.J. Plauger's "The Standard C Library" immensely instructive, as it contains a full implementation of the (then) standard library.
Admittedly, the book is more than 25 years old now, but I'm sure it would still make an interesting read:
It depends on the design of the library. In your case, the answer is "No", because the function isn't isolated in the library. For a good exposition on library construction, see P J Plauger
The Standard C Library 1992. Yes, it is fairly old, so the version of Standard C is C90, but the ideas it espouses are still valid.
When the linker is building a program, it is processing a series of object files and libraries, looking for unsatisfied references (symbol names) and tracking definitions. In most circumstances, it is started with the symbol main as undefined.
As it processes an object file, it notes which symbols are defined that satisfy an undefined symbol and remembers all the names that are defined by that file (and it complains if one of the symbols it finds clashes with one it already knows about).
As it processes a static library, it looks for symbols that are defined that it does not already have a definition for. When it finds such a symbol, it links the object file from the library, noting which symbols are defined and which are still undefined.
Now, if the object file containing symbol_foo only defines symbol_foo, then if you've linked your symbol_foo before it reads the library, the linker will ignore the symbol_foo from the library; it already has a definition and doesn't need another. However, it is probable that the object file containing symbol_foo in the libfoo.a library also defines some other symbols, and those other symbols are needed by the linker, so it has to link the object file containing symbol_foo, and complains because that symbol is doubly-defined, even though others in the same file are not.
Plauger advocates that each object file in a (static) library should define a single external symbol. This allows the maximum substitutability for the functions in the library. I believe it is fair to assume that the designer of libfoo.a didn't make that decision, at least w.r.t symbol_foo.
You can extract the object files from libfoo.a (use a temporary directory) and examine their contents with nm; you may be able to do that directly on the library itself. Used with the proper options, that will show you which files define and reference which other symbols.
Note that the rules for linking with shared libraries are somewhat different. There are also 'weak' symbols which can alter the behaviour. You can also often create 'relocatable' or 'relinkable' object files from multiple object files (ld -r usually); that gives you a single bigger object file and alters the equation. Finally, for now, linker scripts can control which symbols are visible outside the library. So, this is no more than a gloss over the subject.
I'd suggest that P J Plauger
[The Standard C Library](https://smile.amazon.com/dp/0131315099) 1992 still makes good reading — and has a good C90 `printf()` implementation. There were some enhancements required by C99 (notably `long long` support), but the core is more than adequate for your current purposes. I doubt if all the functions are 25 lines long or shorter (many are; some are probably longer).
For an implementation of locales in C90, see
P J Plauger
["The Standard C Library"](https://smile.amazon.com/dp/0131315099) (1992). It's still a good book.
First off, you'll have to learn the rules for each language you learn as it is one of the areas that varies between languages. There's no universal rule about what's what.
Second, in C, you need to know the list of keywords; that seems to be what you're referring to as 'reserved words'. Those are important; they're immutable; they can't be abused because the compiler won't let you. You can't use int as a variable name; it is always a type.
Third, the C preprocessor can be abused to hijack anything; if you compile with #define double int in effect, you get what you deserve, but there's nothing much to stop you doing that.
Fourth, the only predefined variable name is __func__, the name of the current function.
You can apply more sophisticated techniques if you wish (for example, improving the estimate of the fraction), but the frexp() and ldexp() functions are likely to be useful.
I'm pretty sure that the Plauger Standard C Library book has a disc with the source of strtod. http://www.amazon.co.uk/Standard-C-Library-P-J-Plauger/dp/0131315099
and there are online versions too: http://www.google.co.uk/search?hl=en&client=firefox-a&hs=IvI&rls=org.mozilla%3Aen-GB%3Aofficial&q=strtod+source+code
P.J. Plauger, in his book The Standard C Library (which covers implementing the whole library) presents test programs for each part of the library. These are not exhaustive, and I don't have an on-line source for them, but the book is definitely of interest to anyone implementing the library.
If what you want is the documentation for the standard library functions, then P.J. Plauger's "The Standard C Library" http://www.amazon.com/Standard-C-Library-P-J-Plauger/dp/0131315099/ref=sr_1_1?s=books&ie=UTF8&qid=1290273108&sr=1-1 is the best reference. It's got pretty extensive annotation and comentary on the why and how of the standard.
What it does
If you read Plauger's The Standard C Library (1992), you will see that the
<stdio.h>header is allowed to providegetchar()andgetc()as function-like macros (with special permission forgetc()to evaluate its file pointer argument more than once!). However, even if it provides macros, the implementation is also obliged to provid actual functions that do the same job, primarily so that you can access a function pointer calledgetchar()orgetc()and pass that to other functions.That is, by doing:
As written, the
core_function()is pretty meaningless, but it illustrates the point. You can do the same thing with theisxxxx()macros in<ctype.h>too, for example.Normally, you don't want to do that - you don't normally want to remove the macro definition. But, when you need the real function, you can get hold of it. People who provide libraries can emulate the functionality of the standard C library to good effect.
Seldom needed
Also note that one of the reasons you seldom need to use the explicit
#undefis because you can invoke the function instead of the macro by writing:Because the token after
getcharis not an(, it is not an invocation of the function-like macro, so it must be a reference to the function. Similarly, the first example above, would compile and run correctly even without the#undef.If you implement your own function with a macro override, you can use this to good effect, though it might be slightly confusing unless explained.
The function definition line doesn't invoke the macro because the token after
functionis not(. Thereturnline does invoke the macro.Take a look at P.J. Plauger's book The Standard C Library, which describes in detail one possible implementation of the complete C89 standard library.
Admittedly, the book is more than 25 years old now, but I'm sure it would still make an interesting read:
https://www.amazon.com/Standard-C-Library-P-J-Plauger/dp/013...
It depends on the design of the library. In your case, the answer is "No", because the function isn't isolated in the library. For a good exposition on library construction, see P J Plauger The Standard C Library 1992. Yes, it is fairly old, so the version of Standard C is C90, but the ideas it espouses are still valid.
When the linker is building a program, it is processing a series of object files and libraries, looking for unsatisfied references (symbol names) and tracking definitions. In most circumstances, it is started with the symbol
mainas undefined.Now, if the object file containing
symbol_fooonly definessymbol_foo, then if you've linked yoursymbol_foobefore it reads the library, the linker will ignore thesymbol_foofrom the library; it already has a definition and doesn't need another. However, it is probable that the object file containingsymbol_fooin thelibfoo.alibrary also defines some other symbols, and those other symbols are needed by the linker, so it has to link the object file containingsymbol_foo, and complains because that symbol is doubly-defined, even though others in the same file are not.Plauger advocates that each object file in a (static) library should define a single external symbol. This allows the maximum substitutability for the functions in the library. I believe it is fair to assume that the designer of
libfoo.adidn't make that decision, at least w.r.tsymbol_foo.You can extract the object files from
libfoo.a(use a temporary directory) and examine their contents withnm; you may be able to do that directly on the library itself. Used with the proper options, that will show you which files define and reference which other symbols.Note that the rules for linking with shared libraries are somewhat different. There are also 'weak' symbols which can alter the behaviour. You can also often create 'relocatable' or 'relinkable' object files from multiple object files (
ld -rusually); that gives you a single bigger object file and alters the equation. Finally, for now, linker scripts can control which symbols are visible outside the library. So, this is no more than a gloss over the subject.First off, you'll have to learn the rules for each language you learn as it is one of the areas that varies between languages. There's no universal rule about what's what.
Second, in C, you need to know the list of keywords; that seems to be what you're referring to as 'reserved words'. Those are important; they're immutable; they can't be abused because the compiler won't let you. You can't use
intas a variable name; it is always a type.Third, the C preprocessor can be abused to hijack anything; if you compile with
#define double intin effect, you get what you deserve, but there's nothing much to stop you doing that.Fourth, the only predefined variable name is
__func__, the name of the current function.Fifth, names such as
printf()are defined by the standard library, but the standard library has to be implemented by someone using a C compiler; ask the maintainers of the GNU C library. For a discussion of many of the ideas behind the treaty between the standard and the compiler writers, and between the compiler writers and the programmers using a compiler, see the excellent book The Standard C Library by P J Plauger from 1992. Yes, it is old and the modern standard C library is somewhat bigger than the one from C90, but the background information is still valid and very helpful.Reference Style - All Levels
Beginner
Intermediate
Above Intermediate
Uncategorized Additional C Programming Books
Read Plauger's "The Standard C Library" for some insights into why various features of the (C89) standard library are as they are - and in particular why parts of the standard I/O library are as they are. One reason is that C runs on very diverse systems and with diverse media; devices such as tapes may well need to be handled somewhat differently from the disk drive you're accustomed to thinking of. Also, on Unix, consider your 'tty' device - it connects a keyboard and a mouse to a screen - three quite different bits of hardware. Coordinating between those is tricky enough; the rules in the standard make it easier.
The functions from the standard C library that help most are
frexp()andldexp().double frexp(double x, int *p)Returns either 0 or a fraction,
fin the range [0.5 .. 1.0). Sets*pto the power of two such that thef * 2*pequalsx.double ldexp(double x, int p)Returns
x * 2pHence, a decent first approximation to the square root of
xcan be found by:As this code shows, you need at most 5 Newton-Raphson 'divide and average' cycles to produce a fully accurate answer:
Extracts from the output:
You can apply more sophisticated techniques if you wish (for example, improving the estimate of the fraction), but the
frexp()andldexp()functions are likely to be useful.You can find a discussion of this in Plauger's The Standard C Library, and also in Bentley's More Programming Pearls.
Most compilers provide source code for the library - however that source code is usually rather more complex and convoluted than you might expect.
A good resource for this is P.J. Plauger's book, "The Standard C Library", which can be had pretty cheaply if you go for a used one. The code presented is not always straight-forward, but Plauger explains it quite well (and gives the reasons why it can't always be straight-forward and still follow the standard).