Hi,
Check the following code:

#include <stdio.h>

int main()
{
char *s="123.33";

double d=0.0;

d = (double)atof(s);

printf("s is %2$s, d is %1$f\n", d, s);

d = (double)strtod(s, NULL);

printf("s is %3$s, d is %1$.*2$f\n", d, 2, s);

return 0;
}

Output:
s is 123.33, d is 133592.000000
s is 123.33, d is 133592.00

Quite Obvious: I have not included <stdlib.h>
But my code still compiles, because 'libc' is anyways referenced (eg: printf).

=> What are these values returned? This implies there is a 'default' atof which has resolved the symbol reference.

Something interesting now, is i can define atof as a local function: a global symbol and use it as i like.

Now my Question/Problem

But what i was very surprised to see is:
$: nm -A /usr/lib/libc.so.1 | grep atof
/usr/lib/libc.so.1: [3266] | 207888| 12|FUNC |GLOB |0 |9
|atof

'atof' is a symbol with Global visibility in libc.

My questions:
1. Standard C functions should be defined as WEAK symbols, so that a user can override them, like in the above case.
2. However, the resolution in above case has happened due to concept of "interposition" in shared libraries.

Am I correct in concluding this?
Please advice.

C assumes (grrrrr, though a good compiler can warn you) that any function it does not see a prototype for prior to your calling it takes an int and returns an int. Since you did not include stdlib.h, it makes this very incorrect assumption for both atof and strtod. Your explicit cast to double even prevents the warning from popping out (explicit casts can be evil!).

It could be that on your platform, you are truncating/misaligning/generally messing up the return value for atof because C assumes that it is int. Due to this assumption, it is performing an (int) -> (double) conversion rather than the correct (no) conversion. Of course, going into the function it is also performing a (char *) -> (int) conversion, which is unusally (but not impossibly) a source of problems too.

In fact, I just recently had a guy come to me with an odd problem which turned out to be caused by a (void *) -> (int) conversion. He said he was passing a pointer to shared memory into a function and was getting "odd" results from this function. My immediate thought that was that pointers to shared memory on our 64 bit architecture machines likely have more resolution than an int (32 bit) can store (ie the upper half of the pointer value is not just zero'd out). I assumed he must not have had included the header and therefore all pointers passed into the function were being truncated to integer resolution. Hence, the real pointer value was never making it into the function and odd results were occuring. He included the header file, all worked well again, I saved the day, lol.