Do Implict Function Declarations in C Actually Generate Object Code?

In the course of this discussion about casting the return value of malloc many people have claimed that the implicit declaration of malloc would cause the return value to be converted to int then reconverted back to T* possibly resulting in truncation of the pointer in situations where:

sizeof(int) < sizeof(void*)

This would imply that the compiler does the following:

1. Links to and calls the correct object code defining malloc
2. Generates object code to convert the return value to the shorter int type
3. Generates object code to convert back to the larger destination pointer type

Could someone actually prove that this happens? Say with some example code on 64bit Li开发者_如何学Gonux?

I'd do it myself, but I don't have access to a 64 bit machine.

---

The problem with your description of what happens is in step 2. With an implicit declaration, the code at the calling site doesn't "convert" the return value of the function, really.

What happens is that the code at the calling site extracts the return value (typically from a register, or off the stack) by assuming that it's of type "int". The procedure to do this is different for different OSes and compilers, and is typically specified by an ABI document.

For the most common ABIs, the return location and sizes of int and void* are the same, so you actually won't have any problem doing this, even though it's incorrect. This is true for Linux, Windows, and Mac OS X on both 32- and 64-bit platforms, I believe 32-bit platforms.

On 64-bit platforms, it's more common for "long" and "void *" to be the same size, so if you have an implicit declaration for malloc(), the return value will be truncated. There are several popular 64-bit programming models, though.

Back in the "good old days" of DOS development, it was possible to create programs that ran in a mode where "int" was 16 bits, and pointers were 32 bits (actually, 24). In those cases, calling malloc() with an implicit prototype would truncate the returned value.

Note that even in the cases where the return value is truncated, you still might not have a runtime problem, depending on the whether the value is actually outside the valid range of an int.

---

On Mac OS X, in 64-bit mode, this code:

#include <stdio.h>

int main (int argc, const char * argv[]) {
    int x = malloc(128);
    void *p = malloc(128);
    printf("Hello, World!\nsizeof(int)=%d,sizeof(void*)=%d,x=0x%xd,p=%p\n", sizeof(int), sizeof(void *), x, p);
    return 0;
}

prints:

Hello, World! sizeof(int)=4,sizeof(void*)=8,x=0x1001c0d,p=0x100100240

Note that the "x" value has fewer digits than the "p" value, having silently dropped the most-significant 32 bits of the value. The actual assembly code at the two calls to malloc looks like this:

LM2:
    movl    $128, %edi
    call    _malloc
    movl    %eax, -12(%rbp)
LM3:
    movl    $128, %edi
    call    _malloc
    movq    %rax, -8(%rbp)

So, the right value is being returned by malloc (in %rax), but the movl instruction truncates it as it's being moved into variable "x".

---

I think 2 is not quite a "concious" a conversion as you imply. When daling with a function whose return type is unknown the compiler must make some assumption about how many bytes to "grab". The default is the size of an int.

So if a void* and an int happen to be the same size, well and good, if not oops!

---

Malloc is declared in stdlib.h file header and the declaration is included directly by the C preprocessor of your source, which is then linked with malloc code in later stages.

When you have code:

#include <stdlib.h>
...
void * foo = malloc(42);

it's actually proccessed into something like

...
extern void *malloc (size_t __size) __attribute__ ((__nothrow__)) __attribute__ ((__malloc__)) ;
(...lots of other declarations...)
...
void * foo = malloc(42);

When you don't include function prototype, it defaults to something like

int malloc();
...
void * foo = malloc(42);

Which means that the final compiled code will do something like "call malloc with argument 42, convert its return value from int to void* and put it to foo". Then this will get linked with libc that has pre-compiled object code of malloc, which is obviously void*-returning. Therefore, the result will be one extra int-to-void* conversion on CPU register that holds the return value. I imagine that on 64bit architecture it might mean taking lower 32 bits and putting 32 zeroes in front of then, thus clearing part of the original pointer.

---

By omitting the declaration (prototype) for malloc, the compiler assumes it returns int. Calls to it therefore get generated as code to call a function that returns an int result.

How this is done varies depending on your system, so the result may get passed back in a data register, an address register, or on the stack.

The compiler then generates additional code to convert the (presumed) returned int value into a pointer.

Obviously, this is not what you want. You might get lucky on most systems, where ints and pointers are the same width, so the conversion of the returned value essentially does nothing, but you can't rely on this behavior.

So all in all, it's a bad thing not to declare external functions.