Question

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 Linux?

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

Answer 1

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”.