somenath said:
Many thanks for the response. I just fell to understand
this point.
Do a google for "chinese whispers".
C is typically implemented as a series of processes
(roughly following the translation phases set out in
the standard.) Each of these processes typically
carries an element of trust.
The compiler trusts you the programmer.
The linker trusts the compiler.
The host system trusts the linker.
The weak point is at the beginning. If you lie to the
compiler, everyone trusts each other until the program
actually runs and problems surface.
With out prototype compiler assumes that malloc returns
int.
Yes, and it produces some assembler that _assumes_ the
type of value returned when it calls malloc is an int.
On some systems, that means assuming it comes via a data
register, rather than an address register. On other systems
it assumes that 32 bits need to be allocated on a stack,
instead of 64. On still other systems, it assumes it will
arrive in the living room rather than the garage.
Different systems have different calling conventions. Some
systems use machine registers, some use a hardware stack,
others have combinations of the two, and still others use
even wierder mechanisms.
The fundamental point though is that these calling
conventions fall down (usually quite quickly) if the
compiler uses the wrong one. The only clue to the
correct one comes from you the programmer.
But during linking time it will be linked to correct
definition of malloc, which returns (void *). Then in
run time it will be returning (void *) .
But _where_ this void * is returned is crucial. Since the
compiler has been told to expect it via a completely
different type, there is no guarantee that the assembly
code it produces will correctly match up with how the
function actually returns the value.
Is my understanding wrong ?
You are missing the point that C is a statically
typed language. The return type of a function is not
determined at runtime, it is fixed at compile time. In
this regard, C differs from many modern languages that
prefer to figure things out as they run.
Calling a function is like a messaging system. You
pass arguments to the function and it returns one
back to you (if it's a non-void function like malloc).
How those messages are communicated are agreed to in
advance. You stray from the agreed communication lines
at your peril.
Imagine you send off your courier to deliver a message
to Malloc Pty Ltd asking for a delivery of Memory. You
tell your assistant to pick up the returned package at
Gate 15 of bus terminal. But Malloc Pty Ltd always
delivers at Gate 12. So you miss the package.
I did not get this point either. How it is a problem?
Could you please illustrate this point bit more .
Suppose you send a family wagon over to Malloc Pty
Ltd to pick up a package. They then put 2 tonnes of
packages into the back and your tyres blow out before
you even leave the pick up dock. Where you agreed to
send a small utility truck, you sent a wagon, and
now you've paid the cost.